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FOREWORD 


This  plan  for  system  requirements  engineering  defines  the  steps  necessary  to  engineer 
Theater  Ballistic  Missle  Defense  (TBMD)  Navy  Theater  Wide  (NTW)  system.  The  high  level 
architectures  and  requirements  that  result  from  this  process  are  intended  to  guide  future 
development  priorities  and  road  maps,  describe  functional  allocation  alternatives,  and  define 
interface  controls  required  for  safe  and  effective  deployment  of  TBMD  NTW. 

System  alternatives  and  upgrade  priorities  are  established  by  economy  of  force  for  a 
reference  mission  and  time  period.  Cost  is  balanced  with  performance  in  terms  of  defended 
volume,  kill  probabilities,  and  sustainability.  The  tenets  of  life  cycle  cost  reduction,  ease  of 
upgrade,  increased  force  interoperability,  and  TAD  mission  area  optimization  govern  allocation 
of  functions. 


This  publication  has  been  reviewed  by  Mr.  E.R  Whalen,  Head,  Warfare  Systems 
Division. 


Theater  Warfare  Systems  Department 
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GLOSSARY 


NTW  SYSTEM  REQUIREMENTS  ENGINEERING  GLOSSARY 

This  glossary  provides  definitions  of  essential  terms  as  used  in  the  plan  for  executing  NTW  system 
'  requirements  engineering.  This  glossary  is  an  integral  part  of  the  NTW  System  Requirements  Engineering 
and  is  to  be  used  in  the  development  of  documentation  called  for  in  this  document. 

DEFINITIONS 

ATTRIBUTE:  NTW  system  characteristics  which  can  be  organized  into  various  categories  such  as 
functions,  constraints,  performance  parameters,  cost,  physical  characteristics,  supportability  and 
availability. 

ALLOCATED  BASELINE:  The  approved  documentation  describing  the  NTW  element’s  functional, 
performance,  interoperability,  and  interface  requirements  that  are  allocated  from  those  of  the  higher  level 
system,  NTW.  The  Allocated  Baseline  will  include  the  interface  requirements  with  interfacing  sub¬ 
systems;  design  constraints,  derived  requirements  (functional  and  performance);  and  verification 
requirements  and  methods  to  demonstrate  the  achievement  of  those  requirements  and  constraints.  The 
NTW  Allocated  Baseline  will  be  in  the  form  of  a  System  Requirements  Document  (SRD)  for  die  NTW 
nomenclatured  subsystems  and  will  be  the  primary  product  of  Step  4  of  this  plan.  The  SRDs  will  be  the 
basis  for  the  Program  Manager’s  implementation  of  the  nomenclatured  systems. 

CONCEPTUAL  PERFORMANCE  BASELINE  (CPB):  The  documentation  that  identifies  the  NTW 
performance  concept  chosen  to  meet  the  needs  identified  in  the  top  level  operational  requirements 
documents.  The  Conceptual  Performance  Baseline  includes  broad  objectives  and  thresholds  for  key  cost, 
schedule  and  performance  parameters,  including  supportability.  Objectives  will  include  thresholds 
identifying  minimum  acceptable  requirements.  The  initial  CPB  will  be  the  primary  product  of  Step  3  of  the 
system  requirements  engineering  process  described  in  this  plan.  Reevaluation  of  alternative  concepts  or 
approaches  will  be  performed  if  Step  4  of  this  plan  determines  that  key  parameters  are  not  met. 

CONCEPTUAL  PERFORMANCE  BASELINE  REVIEW  (CPBR):  The  formal  review  of  the  results 
of  Step  3  of  the  NTW  system  requirements  engineering  process. 

CONCEPT  OF  OPERATIONS  (CONOPs):  A  document  that  addresses  the  operational  employment  of  a 
system(s). 

DESIGN  REFERENCE  MISSION  (DRM):  A  detailed  description  of  the  operational  environment 
within  which  the  NTW  system  attributes  and  requirement  allocations  are  evaluated  and  are  used  to  evaluate 
the  relative  merit  of  proposed  system  concepts  and  upgrades.  It  defines  the  total  envelope  of  the 
operational  environments  in  which  NTW  must  perform  from  the  early  stages  of  initial  presence  to  the  end 
of  hostilities  and  in  the  key  products  of  Step  1. 

FUNCTIONAL  BASELINE:  The  approved  documentation  describing  the  NTW  functional,  performance, 
interoperability,  interface  requirements,  and  the  verification  required  to  demonstrate  the  achievement  of 
those  specified  requirements.  The  basis  for  the  Functional  Baseline  is  the  CPB  defined  in  Step  3.  The 
Functional  Baseline  is  finalized  in  Step  4  of  this  plan. 

FUNCTIONAL  DESCRIPTION:  Hierarchical  description  of  the  functions  to  be  performed  by  the  future 
NTW  “system  of  systems”  required  to  meet  the  full  set  of  NTW  operational  requirements.  This  functional 
model  is  developed  from  the  functionality  of  current  NTW  systems  and  a  functional  decomposition  of 
NTW  related  operational  requirements. 
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INTEGRATED  PRODUCT  TEAM:  Team  composed  of  representatives  from  all  appropriate  functional 
disciplines  working  together  with  a  Team  Leader  to  build  successful  and  balanced  programs,  identify  and 
resolve  issues,  and  make  sound  and  timely  recommendations  to  facilitate  decision-making. 

LIFE  CYCLE  COST  (LCC):  The  sum  total  of  the  direct,  indirect,  non-recurring,  and  other  related  costs 
incurred,  or  estimated  to  be  incurred,  in  the  design,  development,  production  (including  manufacture  and 
fabrication),  acquisition,  test  and  evaluation,  acceptance,  operation,  maintenance,  modernization, 
deactivation,  and  support  of  a  configuration  item  over  its  anticipated  life  span. 

LIFE  CYCLE  COST  ANALYSIS:  The  identification,  quantification,  and  qualification  of  LCC  by 
segment  with  the  purpose  of  establishing  the  cost  interrelationships  and  the  effect  of  each  contributor  to  the 
total  LCC. 

MEASURE  OF  EFFECTIVENESS  (MOE):  Metric  used  to  quantify  a  systems  ability  to  meet  its 
operational  objectives.  Examples  of  top  level  MOEs  include  probability  of  killing  or  countering  a  threat, 
system  availability,  defended  area  etc.  Top  Level  MOEs  may  be  decomposed  into  supporting  MOEs. 
MOEs  are  typically  evaluated  for  a  specific  or  a  series  of  operational  situations  or  scenarios.  MOEs  are 
used  to  derive  lower  level  technical  performance  requirements  that  are  allocated  to  specific  functions  and 
subsystems. 

MIGRATION  PATH:  A  plan  of  actions  and  milestones  that  addresses  the  evolution  of  the  current 
AEGIS  Combat  System  to  the  FY2010  baseline. 

MISSION  SUCCESS  CRITERIA:  Quantitative  criteria  to  be  used  to  assess  if  a  ship,  battle  group,  joint 
command,  etc.  will  meet  an  assigned  mission.  The  system  being  evaluated  may  be  inherently  involved  in 
the  mission,  or  it  may  play  only  an  enabling  role.  An  example  would  be  that  the  battle  group  was  able  to 
successfully  defend  a  specific  area  against  ballistic  missiles  with  a  99%  probability  of  success. 

MISSION  SYSTEM  REQUIREMENTS  REVIEW  (MSRR):  The  final  formal  review  and  approval 
event  conducted  as  Step  5  of  the  NTW  system  requirements  engineering  process. 

OPERATIONAL  REQUIREMENTS  REVIEW:  The  formal  review  of  the  results  of  Step  0  (Operational 
Needs  and  Requirements),  Step  1  (Define  the  Operational  Environment),  and  Step  2  (Define  System 
Boundaries),  of  the  NTW  system  requirements  engineering  process. 

OPERATIONAL  REQUIREMENTS  TRACEABILITY  MATRIX:  A  matrix  which  traces  operational 
requirements  from  the  top  level  mission  area  down  to  the  specific  element  /  nomenclatured  system.  The 
matrix  shows  the  decomposition  and  relationship  of  operational  requirements  and  will  be  correlated  with 
functional  requirements. 

PERFORMANCE  REQUIREMENT:  The  extent  to  which  a  mission  /  operation  or  function  must  be 
executed,  generally  measured  in  terms  of  quantity,  quality,  coverage,  timeliness,  or  readiness. 

SURFACE  NAVY  THEATER  AIR  DEFENSE  (SURFACE  NAVY  TAD)  SYSTEM:  An  integrated 
system  which  is  comprised  of  all  Surface  Navy  related  Theater  Air  Defense  resources  and  their  interfaces 
with  non-Surface  Navy  TAD  and  other  Navy  assets. 

SYSTEM  REQUIREMENTS  DOCUMENT:  A  Requirements  document  that  translates  operational 
requirements  into  functional,  technical  performance,  interface,  interoperability,  and  verification 
requirements  and  allocates  those  requirements  to  lower  level  subsystems.  It  defines  the  environment  that 
the  system  must  operate  in  as  well  as  the  threats  that  the  system  must  address. 
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EXECUTIVE  SUMMARY 


Ref:  (a)  COMNAVSEASYSCOM  Memo  Ser  TAD-SE  8003  of  10  Feb  97 

(b)  Volume  I:  System  Requirements  Engineering  of  the  Systems  Engineering  Plan  for  Surface 
Navy  TAD,  dated  12  November,  1997 

Reference  (a)  established  a  pilot  program  for  systems  engineering  in  the  Naval 
Sea  Systems  Command  (NAVSEA)  commencing  with  the  Theater  Air  Defense  (TAD) 
warfare  mission  area  and  assigned  actions  for  the  implementation  of  this  pilot. 
PEO(TAD)-SE  drafted  Volume  I  (System  Requirements  Engineering)  of  the  Systems 
Engineering  Plan  (SEP)  for  Navy  Theater  Wide  Theater  Ballistic  Missile  Defense  (NTW 
TBMD)  requirements  for  Navy  surface  combatants.  Hereafter  for  brevity.  Navy  Theater 
Wide  Ballistic  Missile  Defense  will  be  referred  to  as  NTW. 

Volume  I,  which  follows,  describes  the  process  to  be  followed  in  developing 
NTW  requirements  for  Navy  surface  combatants.  Volume  I  addresses  the  need  to 
develop  an  integrated  set  of  detailed  requirements  for  each  Surface  Navy 
system/subsystem  that  will  become  an  integral  part  of  the  implementation  of  an  NTW 
capability.  An  equally  important  objective  of  this  plan  is  to  develop  a  Systems 
Requirements  Document  (SRD)  for  the  NTW  mission  and  product  programs.  The  plan 
also  provides  the  basis  for  scheduling,  costing,  tracking  and  controlling  this  system 
requirements  engineering  effort.  This  document  represents  the  initial  portion  of  the 
systems  engineering  process.  Volume  II,  which  will  detail  the  remainder  of  the  NTW 
systems  engineering,  will  be  developed  under  the  direction  of  PMS  452.  In  addition, 
product  specific  Systems  Engineering  Management  Plans  (SEMPs)  will  be  developed  by 
the  respective  program  offices. 

•  Reference  (b),  developed  by  NSWCDD  for  PEO(TAD)-SE,  is  part  of  the  overall 
Theater  Air  Defense  system  requirements  engineering  thrust  and  was  the  basis  from 
which  this  system  requirements  engineering  plan  was  developed.  Additional  guidance 
provided  in  EIA/IS-  632  Interim  Standard  Systems  Engineering,  Department  of  Defense 
(DOD)  directives  and  DOD  5000.1  and  5000.2  series  instructions  was  also  incorporated 
into  the  development  of  this  NTW  system  requirements  engineering  plan.  Execution  of 
the  plan  will  be  jointly  led  by  NSWCDD  and  the  Johns  Hopkins  University  Applied 
Physics  Lab  (JHU/APL)  under  the  guidance  of  PEO(TAD)-SE. 


This  system  requirements  engineering  plan  provides  detailed  guidance  for  the 
execution  of  TAD  system  requirements  engineering  assessment,  management  and 
allocation  activities  at  the  NTW  Theater  Ballistic  Missile  Defense  (TBMD)  mission  level 
in  the  context  of  Joint  Theater  Warfare.  This  system  requirements  engineering  effort  will 
build  on  the  Area  and  NTW  efforts  to  date  and  apply  additional  systems  engineering  rigor 
to  ensure  functional  completeness  and  efficiency  in  establishing  the  requirements  for 
NTW.  Volume  I  applies  systems  engineering  principles,  appropriately  tailored,  to 
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determine  performance,  functional  and  interface  requirements  and  the  allocation  of  those 
requirements  to  the  Navy  nomenclatured  systems  to  create  a  cost,  schedule  and 
performance  balanced  NTW  capability  that  supports  achievement  of  joint  TBMD  mission 
objectives. 

This  plan  describes  the  process  for  developing  an  SRD  that  addresses  and 
allocates  requirements  for  the  NTW  Mission  Program  and  related  product  programs.  The 
objective  is  a  performance,  cost  and  schedule  balanced  set  of  requirements  that  enable  the 
development  of  a  NTW  capability  with  an  optimized  contribution  to  the  Joint  TBMD 
Mission  circa  FY  2010.  It  is  recognized  that  many  system  elements  have  a  multiplicity  of 
functions  encompassing  other  warfare  areas.  However,  the  NTW  functions  will  be  the 
focus  of  this  system  requirements  engineering  effort  with  only  limited  attention  given  to 
non-NTW  functionality.  The  major  products  of  this  systems  engineering  process  are  as 
follows: 

•  NTW  Functional  Baseline,  System  Architecture  and  Allocated  Baseline* 
which  will  be  documented  in  the  SRD; 

•  Final  NTW  System  Requirements  Document; 

•  Migration  Path  Report  describing  how  to  achieve  the  NTW  baseline; 

•  Non-NTW  Systems  Interface  Requirements  Recommendation  Report; 

•  Naval  TBMD  ORD  recommendations; 

•  Technology  Development  Requirements  Report; 

•  Interface  Sensitivity  Analysis  Report; 

•  Risk  Reduction  Prioritization  Report;  and 

•  Design  Reference  Mission. 

The  system  requirements  engineering  process  defined  in  this  plan  is  a  six-step 
process  in  which  was  tailored  from  classic  systems  engineering  principles.  This  six-step 
process  is  shown  in  Figure  1-2  and  discussed  in  detail  in  Section  II  of  this  plan.  A  brief 
description  of  each  step  is  provided  below: 

•  Step  0:  Identify  Operational  Needs  and  Requirements. 

This  step  identifies  and  traces  the  mission  needs  and  operational  requirements 
from  the  Joint  TBMD  Capstone  Requirements  Document  to  NTW.  The 
requirements  traceability  analysis  will  provide  insight  into  the  completeness  and 
consistency  of  the  NTW  requirements  and  allow  the  documentation  of  draft 
recommended  changes  and  modifications  to  the  Naval  TBMD  ORD. 


*  The  Allocated  Baseline  in  this  case  is  documented  in  the  SRD  which  the  respective 
Program  Offices  will  use  to  develop  their  combat  system  products. 


xi 


NSWCDD/MP-99/12 


•  Step  1:  Define  the  Operational  Environment. 

This  step  defines  the  NTW  Design  Reference  Mission  (DRM)  which  details  the 
operational  environment  within  which  the  system  attributes  and  requirement 
allocations  are  evaluated.  The  DRM  will  be  defined  in  the  context  of  an  evolving 
campaign  with  the  build-up  of  a  Joint  Task  Force  and  will  contain  design¬ 
stressing  features  to  evaluate  all  of  the  operational  requirements.  The  DRM  will 
be  the  baseline  used  in  Steps  3  and  4  to  evaluate  the  relative  merit  of  proposed 
system  concepts  and  upgrades  for  NTW. 

•  Step  2:  Define  the  System’s  Boundaries. 

This  step  describes  the  functions  to  be  performed  by  NTW  and  the  boundaries  and 
interrelationships  of  NTW  and  its  subsystems  with  other  Joint  Theater  Warfare 
systems  and  subsystems.  This  step  will  document  NTW  interfaces  and 
information  flow  and  identify  areas  where  functional  relationships  cross  system 
boundaries  and  may  result  in  potential  performance  sensitivities. 


•  Step  3:  Identify  NTW  System/Subsystem  Key  Attributes. 

This  step  identifies  the  key  NTW  system  and  subsystem  attributes  that 
significantly  contribute  to  the  successful  completion  of  the  NTW  mission  and 
translates  these  findings  into  a  Conceptual  Performance  Baseline  (CPB) 
comprised  of  top-level  functional  and  performance  requirements  for  NTW . 

Step  4:  Establish  the  NTW  Functional/Allocated  Baseline. 

This  step  evaluates  system  alternatives,  establishes  the  NTW  Functional  Baseline 
(performance,  functional,  cost,  physical)  and  allocates  this  baseline  to  existing 
and  proposed  subsystems.  A  NTW  SRD  will  be  used  to  document  the  baseline 
and  will  be  used  by  the  respective  program  offices  to  develop  their  combat 
systems  products.  The  SRD  will  define  functional,  interface,  performance  and 
verification  requirements.  The  migration  plan  to  achieve  the  performance/cost 
balance  NTW  capability  will  also  be  defined  in  this  step. 

•  Step  5:  Conduct  a  Mission  System  Requirements  Review  (MSRR). 

This  system  requirements  engineering  process  culminates  with  the  MSRR  during 
which  the  NTW  Functional  and  Allocated  Baselines,  migration  path,  non-NTW 
interface  requirements  recommendations,  technology  development  requirements 
and  supporting  analysis  reports  are  presented  to  the  Navy’s  senior  leadership  for 
concurrence  and  transition  to  Program  Managers  (PM’s)  for  development  of  their 
combat  systems  products. 

Throughout  the  execution  of  this  plan,  efforts  will  be  made  to  utilize  the  analysis 
and  findings  of  the  past  and  ongoing  TBMD  studies  including  the  Navy  TBMD  COEA 
and  the  Systems  Engineering  Technical  Assessment  Team  (SETAT)  Phase  I/II.  The 
analysis  outlined  in  this  plan  supplements  the  work  of  those  studies  and  ensures  a 
documented  comprehensive  top-down  systems  engineering  evaluation  of  all  aspects  of 
NTW. 
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SECTION  1.0  -  OVERVIEW 


1.1  INTRODUCTION 

The  Program  Executive  Officer,  Theater  Air  Defense  Systems  Engineering  (PEO(TAD)- 
SE)  drafted  Volume  I  (System  Requirements  Engineering)  of  the  Systems  Engineering  Plan 
(SEP)  for  Navy  Theater  Wide  Theater  Ballistic  Missile  Defense  (NTW  TBMD)  capabilities  for 
Navy  surface  combatants.  Hereafter  for  brevity,  Navy  Theater  Wide  Theater  Ballistic  Missile 
Defense  will  be  referred  to  as  NTW.  In  response  to  PEO(TAD)-SE  tasking.  Volume  I  of  the 
NTW  SEP  was  developed.  Volume  I  describes  the  process  to  be  followed  in  defining  NTW 
requirements  for  Navy  surface  combatants.  The  requirements  engineering  effort  defined  in  this 
document  represents  the  initial  portion  of  the  NTW  systems  engineering  process. 

The  NTW  system  requirements  engineering  process  is  a  part  of  the  TAD  systems 
engineering  strategy.  Volume  I  (System  Requirements  Engineering)  of  the  Surface  Navy  TAD 
Systems  Engineering  Plan,  developed  by  the  Naval  Surface  Warfare  Center  Dahlgren  Division 
(NSWCDD)  for  PEO(TAD)-SE  and  dated  12  November  1997,  was  the  basis  from  which  this 
NTW  System  Requirements  Engineering  Plan  was  developed.  Guidance  provided  in  ELA/IS-632 
Interim  Standard  Systems  Engineering,  DOD  directives  and  DOD  5000.1  and  5000.2  series 
instructions  was  also  incorporated  into  the  development  of  this  NTW  plan. 

This  plan  addresses  NTW  System  Requirements  Engineering  prior  to  Milestone  II  and 
provides  the  basis  for  scheduling,  costing,  tracking  and  controlling  the  NTW  Program’s  system 
requirements  engineering  effort.  This  effort  will  develop  a  comprehensive  set  of  technical 
system  requirements  allocated  to  the  product  programs  with  traceability  to  top  level  operational 
requirements.  Volume  II  will  detail  the  remainder  of  the  NTW  systems  engineering  effort  and 
will  be  developed  under  the  direction  of  PMS  452.  In  addition,  product  specific  systems 
engineering  management  plans  (SEMPs)  will  be  developed  by  the  respective  program  offices. 


1.2  NTW  PROGRAM  OVERVIEW 

The  Navy  is  currently  implementing  a  TBMD  capability.  This  effort  will  provide  the 
earliest  cost-effective  capability  by  upgrading  existing  systems  and  leveraging  on  substantial  past 
investment  in  these  systems  and  their  infrastructure.  The  Navy’s  approach  entails  two 
acquisition  programs:  Navy  Area  TBMD  and  NTW.  The  Navy  Area  TBMD  Program’s  initial 
capability  will  be  accomplished  by  modifying  the  Navy’s  AEGIS  Weapon  System  (AWS)  and 
integrating  the  design  of  the  STANDARD  Missile  2  Block  IV A  to  enable  detection,  control  and 
endo-atmospheric  engagement  of  TBM’s.  However,  additional  development  is  required  to 
expand  the  area  defense  foundation  to  full  theater  capability  and  to  provide  protection  against 
medium/long  range  TBM’s  for  Joint  Forces,  sea  and  air  lines  of  communications,  command  and 
control  nodes,  vital  political  and  military  assets,  supporting  infrastructure,  population  centers, 
and  inland  regions  within  the  entire  theater.  The  NTW  program  is  evolving  the  AEGIS  Combat 
System’s  (ACS)  core  elements  (AWS  -  including  STANDARD  Missile  (SM)  and  Vertical 
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Launching  System  (VLS))  and  existing  battle  management,  command,  control,  and 
communication  systems  into  a  TBMD  system,  with  capabilities  to  engage  mid  to  long  range 
TBM’s  during  their  exo-atmospheric  flight. 

To  minimize  development  risk  inherent  in  this  challenging  endeavor,  a  multi-faceted, 
evolutionary  development  approach  is  being  pursued.  The  current  NTW  development  approach 
consists  of  two  major  efforts.  One  effort  is  focused  on  conducting  the  AEGIS  Lightweight  Exo- 
Atmospheric  Projectile  (LEAP)  Intercept  (ALI)  demonstration.  The  other  effort  is  composed  of 
several  risk  reduction  activities  (RRA)  that  are  focused  on  reducing  specific  known  technical 
risks  in  the  development  of  a  NTW  tactical  system.  Upon  successful  completion  of  the 
demonstration,  ALI  has  the  potential  to  provide  a  tactical  stepping  stone  (providing  limited 
capability)  which  could  be  deployed  on  the  road  to  a  full  capability  system.  This  early  capability 
is  referred  to  as  Block  I  (BLK I)  and  full  capability  is  referred  to  as  BLK II. 

The  ALI  includes  a  series  of  near-term  flight  tests  which  are  focused  on  demonstrating 
that  LEAP  technologies  can  be  integrated  with  a  modified  STANDARD  Missile  (SM-3)  and 
AWS  to  perform  exo-atmospheric  TBM  intercepts.  The  primary  objectives  of  ALI  is  to 
demonstrate  collision  guidance  and  physically  hit  a  TBM  target  with  a  kinetic  warhead  (KW) 
launched  from  an  AEGIS  ship.  The  ALI  demonstration  was  defined  to  incorporate  maximum 
heritage  from  the  TERRIER  LEAP  demonstration  and  the  current  Navy  Area  TBMD  User 
Operational  Evaluation  System  (UOES)  program.  This  demonstration  consists  of  a  series  of 
increasingly  challenging  flight  tests  designed  to  validate  intercept  performance  capability  with 
live  test  data.  The  initial  series  of  flight  tests  are  designated  Control  Test  Vehicles  (CTVs)  and 
are  designed  to  successively  test  the  next  level  of  SM-3/AWS  integration.  The  second  series  of 
SM-3  flight  tests,  designated  Guided  Test  Vehicle  (GTV),  will  demonstrate  the  physical  intercept 
of  a  LEAP  KW  with  a  TBM  representative  target  in  exo-atmospheric  flight.  The  NTW  tactical 
system  will  evolve  from  this  demonstration. 

The  RRAs  are  designed  to  reduce  significant  technology  development  risks  early, 
allowing  a  rapid  low  risk  development  of  an  early  capability  and/or  the  tactical  system.  The 
purpose  of  the  RRAs  are  to  make  investments  in  the  critical  technologies  necessary  to  assure  the 
capability  of  the  NTW  System  to  counter  an  evolving  threat.  Earlier  system  analyses  indicate 
that  key  aspects  of  NTW  will  be  stressed  by  advancements  in  threat  capability  and  RRAs  will 
provide  a  hedge  against  such  breakouts  or  countermeasures.  This  activity  is  directed  at  those 
critical  technologies  which  include,  detection  and  track  processing;  discrimination,  both 
interceptor  and  ship  based  sensors;  propulsion  and  divert;  and  lethality.  This  four-year  effort 
includes  development  and  demonstration  of  algorithms,  ship  based  architecture  assessment  and 
modification,  hardware  design/development/demonstration,  bench  tests  and  experiments 
culminating  in  a  framework  and  environment  to  test  NTW  systems  and  technologies. 

In  addition,  at  the  beginning  of  FY97,  the  Navy  initiated  a  NTW  Cost  and  Operational 
Effectiveness  Analysis  (COEA)  directed  at  supporting  a  Defense  Acquisition  Board  (DAB).  The 
COEA  reported  out  during  the  last  quarter  of  FY97.  The  objective  of  the  Navy  TBMD  COEA 
Phase  II  was  to  estimate  the  cost  and  performance  of  various  interceptor  candidates  for  the  NTW 
mission.  These  estimates  along  with  results  from  special  studies  on  target  detection  and 


1-2 


NSWCDD/MP-99/12 


processing,  exo-atmospheric  discrimination,  endgame  effectiveness  and  marinization  will  be 
used  to  give  recommendations  on  a  material  selection  for  the  NTW  interceptor. 


1.3  PURPOSE 

In  general,  the  purpose  of  implementing  a  systems  engineering  process  is  threefold: 

•  To  ensure  all  system  requirements,  specified  or  derived,  are  incorporated  into  the 
system  design  and  are  verifiable; 

•  To  optimize  the  development  process  for  the  product  to  be  provided  for  the 
warfighter  by  maintaining  a  traceable,  integrated  baseline;  and 

•  To  readily  allow  assessment  of  overall  design  maturity  and  risk  during  the  decision 
making  process  to  avoid  costly  downstream  design  changes  and  cost  or  schedule 
growth. 

This  volume  of  the  NTW  SEP  partially  addresses  the  above  general  purposes  and  is 
focused  on  providing  detailed  guidance  for  the  execution  of  TAD  system  requirements 
engineering  assessment,  management  and  allocation  activities  at  the  TBMD  mission  level  for 
NTW  in  the  context  of  Joint  Theater  Warfare.  This  requirements  engineering  effort  will  build  on 
the  Area  and  NTW  efforts  to  date  and  apply  additional  systems  engineering  rigor  to  ensure 
functional  completeness  and  efficiency  in  establishing  the  requirements  for  NTW.  Volume  I 
applies  systems  engineering  principles,  appropriately  tailored,  to  determine  performance, 
functional  and  interface  requirements  and  the  allocation  of  those  requirements  to  the  individual 
Surface  Navy  TAD  nomenclatured  systems  to  create  a  performance,  cost  and  schedule  balanced 
NTW  capability  that  supports  achievement  of  Joint  TBMD  mission  objectives. 

This  plan  defines  the  process  to  be  used  in  establishing  requirements  for  individual 
nomenclatured  systems  to  ensure  that  they  support  overall  NTW  requirements  and  addresses  the 
System  Requirements  Engineering  prior  to  Milestone  II.  Because  NTW  is  a  part  of  the  overall 
Surface  Navy  TAD  strategy,  the  processes  addressed  in  this  plan  are  part  of  the  overall 
PEO(TAD)-SE  systems  engineering  thrust  described  in  the  Surface  Navy  TAD  Systems 
Engineering  Plan  which  prescribes  the  systems  engineering  effort  for  the  Surface  Navy  TAD 
“system  of  systems”  and  individual  nomenclatured  systems.  Volume  I  does  not  explicitly 
address  all  of  the  systems  engineering  processes  to  be  used  by  individual  NTW  elements  (i.e., 
nomenclatured  systems)  once  functional,  performance,  interface  and  interoperability 
requirements  have  been  established  by  the  systems  engineering  effort  defined  in  this  plan. 


1.4  SCOPE 

Figure  1-1  illustrates  the  scope  of  NTW  in  the  larger  system  context  of  Joint  TBMD.  The 
product  programs  in  the  bottom  line  of  systems  or  elements  of  systems  which  can  be  employed 
to  perform  NTW  today  and  provide  a  baseline  from  which  future  systems  can  be  built  to  perform 
future  NTW  TBMD.  The  non-NTW  systems  will  be  represented  in  this  effort  as  top-level 
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performance  elements  with  their  respective  interfaces  to  NTW.  Within  Navy  TBMD  as  shown 
in  Figure  1-1,  there  are  three  levels  that  support  Joint  TBMD: 

•  Navy  TBMD  Mission  Area; 

•  NTW  Mission  Program;  and 

•  Product  Programs  (nomenclatured  systems). 


Figure  1-1.  PEO(TAD)-SE  Common  System  Requirements  Engineering  Process 


One  intent  of  this  plan  is  to  define  the  process  for  developing  a  NTW  System 
Requirements  Document  (SRD)  that  addresses  and  allocates  requirements  for  each  of  these 
levels.  The  objective  is  a  performance,  cost  and  schedule  balanced  set  of  requirements  that 
enable  the  development  of  a  NTW  capability  with  an  optimized  contribution  to  the  Joint  TBMD 
Mission. 

It  is  recognized  that  some  NTW  System  elements  have  a  multiplicity  of  functions 
encompassing  other  warfare  areas.  However,  the  NTW  functions  will  be  the  focus  of  this  system 
requirements  engineering  effort  with  only  limited  attention  to  non-NTW  functionality. 
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The  common  system  requirements  engineering  process  which  is  composed  of  Steps  0 
through  5  is  illustrated  in  Figure  1-2.  This  common  process  has  been  tailored  for  NTW  system 
requirements  engineering  which  will  be  discussed  in  detail  in  Section  II. 


Figure  1-2.  Management  Structure  for  NTW  System 
Requirements  Engineering  Execution 


Work  will  begin  with  efforts  to  identify  and  organize  existing  mission  needs  and 
operational  requirements  pertaining  to  the  NTW  System.  The  Design  Reference  Mission  (DRM) 
will  be  defined  from  both  Navy  and  Joint  perspectives  and  will  be  based  on  Defense  Planning 
Guidance  and  consideration  of  design  stressing  aspects  of  the  TBMD  mission.  Steps  will  be 
taken  to  determine  system  functions  and  boundaries  and  key  attributes  of  NTW.  A  Conceptual 
Performance  Baseline  (CPB)  will  be  developed  that  includes  top-level  functional  and 
performance  requirements  for  NTW. 

A  series  of  assessments  will  be  conducted  to  evaluate  candidate  NTW  implementation 
concepts  stressing  performance  and  life-cycle  cost  at  the  TBMD  Mission  Area  to  provide  the 
following  results: 

•  Determine  NTW  cost  balanced  performance  and  functional  requirements  for 
candidate  enhancements  and/or  new  developments  in  the  form  of  a  SRD  that 
addresses  each  product  element  (nomenclatured  system);  and 

•  Define  the  migration  path  to  the  performance/cost  balanced  NTW  fully  capable 
system. 
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Alternative  concepts  will  be  refined  throughout  the  assessment  process  to  provide  the 
best  possible  basis  for  the  Allocated  Baseline  definition.  An  SRD  and  migration  paths  will  then 
be  prepared  as  appropriate  to  support  a  Mission  System  Requirements  Review  (MSRR)  for 
NTW.  The  focus  of  this  plan  is  on  pre-Milestone  II  aspects  of  NTW.  This  effort  (Steps  0-5)  will 
take  full  advantage  of  all  past  and  ongoing  efforts  and  will  make  maximum  utilization  of  existing 
documentation  and  analyses,  i.e..  Global  Protection  Against  Limited  Strike  (GPALS)  Feasibility 
Study,  ASN  Anti-Tactical  Ballistic  Missile  (ATBM)  Study,  Concept  Evaluation  Integration 
Study  (CEIS),  AEGIS/Theater  High  Altitude  Air  Defense  (THAAD)  Integration  Study,  Navy 
TBMD  COEA  Phase  Eli,  SET  AT  Phase  Eli,  etc.  This  effort  provides  the  framework  in  which  a 
structured  system  requirements  engineering  process  maps  functional  requirements  to  the  NTW 
Mission  area.  Additional  analysis  will  occur  when  holes  and  deficiencies  are  identified  or  when 
concerns  at  the  Joint  Mission  Area  require  further  investigation. 

The  SRD  will  be  the  basis  for  the  Program  Managers'  development  of  the  nomenclatured 
subsystems  to  implement  the  NTW  capability.  Figure  1-3  shows  the  relationship  of  the  NTW 
SRD  to  the  warfighter  generated  Top  Level  Operational  Requirements  and  to  the  individual 
program  Top  Level  Requirements  (TLRs)  and  specifications.  In  addition  to  the  NTW  SRD,  the 
system  requirements  engineering  process  will  provide  recommendations  for  additions  and 
modifications  to  the  Naval  TBMD  ORD  as  appropriate. 


Figure  1-3.  NTW  System  Requirements  Engineering  Document  Framework 
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Figure  1-4  illustrates  the  relationship  of  the  system  requirements  engineering  process 
described  in  this  plan  to  the  general  acquisition  milestones  and  the  remainder  of  the  system 
development  process.  This  system  requirements  engineering  process  will  determine  the  NTW 
Conceptual  Performance,  Functional  and  Allocated  baselines.  The  mission  and  product  program  , 
managers  are  responsible  for  taking  the  allocated  requirements  and  developing  the  individual 
systems  which  constitute  the  NTW  System.  The  mission  and  product  program  managers  will  be 
responsible  for  establishing  processes  in  their  individual  SEMPs  to  maintain  traceability  to  the 
NTW  requirements.  Since  the  NTW  system  requirements  engineering  process  will  only  generate 
a  top  or  first  level  allocation,  additional  iterations  of  the  system  engineering  process  are 
performed  by  the  product  program  managers  to  define  the  lower  level  allocated  and  product 
baselines.  These  product  baselines  will  be  used  for  the  actual  development  of  the  equipment  and 
computer  programs. 


1.5  TECHNICAL  PROGRAM  MANAGEMENT  AND  CONTROL 

Management  and  control  activities  are  intended  for  directing,  tracking,  and  reviewing 
program  accomplishments,  results,  and  risks  against  documented  estimates,  commitments,  and 
plans.  Appropriate  corrective  actions  can  then  be  taken  when  performance  deviates  significantly 
from  plans. 


1.5.1  General  Systems  Engineering  Roles  and  Responsibilities 

The  general  system  requirements  engineering  roles  and  responsibilities  are  taken  from  the 
16  June  1997  draft  PEO(TAD)  guidance  and  policy  paper  on  TAD  systems  engineering  roles  and 
responsibilities.  The  significant  investment  in  people  and  facilities  necessary  to  execute  each 
phase  of  the  system  requirements  engineering  process  requires  organizational  focus  and 
commitment  for  proper  execution.  The  need  to  develop  solutions  that  optimize  cost  and 
effectiveness  at  the  TAD  mission  level  of  system  make  it  necessary  to  establish  a  more  formal 
and  enduring  structure  for  the  execution  of  system  requirements  engineering.  PEO(TAD)  has 
assigned  the  following  roles  and  responsibilities  for  Navy  TAD  systems  engineering.  Leadership 
roles  do  not  imply  exclusive  dominance. 

1.5. 1.1  TAD  Systems  Engineer 

The  PEO(TAD)  Systems  Engineer,  TAD-SE,  is  responsible  to  the  PEO  for  the  technical 
and  system  architecture  of  all  TAD  systems.  TAD-SE  defines  the  system  engineering  process 
that  TAD  programs  will  follow  and  provides  budget  inputs  to  Program  Managers  (PMs)  for 
implementation  of  that  defined  system  engineering  process.  Important  to  this  process  is 
allocation  of  functions  to  systems  and  components  for  Program  Manager  (PM)  implementation. 
TAD-SE  will  direct  the  PEO  systems  engineering  processes,  including  those  at  Johns  Hopkins 
University/ Applied  Physics  Laboratory  (JHU/APL)  and  Naval  Surface  Warfare  Center,  Dahlgren 
Division  (NSWCDD).  TAD-SE  is  charged  with  supporting  PMs  in  the  overall  implementation 
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1.5. 1.2  Systems  Concept  Eneineer 

The  Johns  Hopkins  University/ Applied  Physics  Laboratory  (JHU/APL)  is  assigned  the 
role  of  PEO(TAD)  Conceptual  Systems  Engineer.  In  this  role,  JHU/APL  shall  develop  system 
concepts,  with  risk  reduction  approaches  including  prototyping  as  necessary,  for  all  TAD 
systems  and  major  upgrades.  These  concepts  shall  be  formulated  into  a  Conceptual  Performance 
Baseline  which  will  be  the  basis  for  Functional  Baselines  for  TAD  systems.  JHU/APL  shall 
certify  to  PEO(TAD)  that  the  Conceptual  Performance  Baseline  and  its  functional  allocation 
satisfies  the  mission  need  with  a  design  that  is  balanced  in  performance,  cost  and  schedule. 
JHU/APL  shall  continue  to  monitor  the  development  to  assure  that  the  integrity  of  the  concept 
and  its  performance  is  maintained  as  the  development  matures.  JHU/APL  will  have  a  supporting 
role  in  the  development  of  Allocated  Baselines.  The  objectivity  necessary  to  carry  out  this  role 
precludes  assignment  of  design  agent  functions  to  the  system  concept  engineer  except  under 
special  circumstances  approved  by  the  PEO. 

1.5. 1.3  Systems  Development  Engineer 

The  NSWCDD  is  assigned  the  role  of  PEO(TAD)  Systems  Development  Engineer. 
NSWCDD  has  the  responsibility  to  accept  the  Functional  Baseline  for  the  Program  Manager. 
Acceptance  of  the  Functional  Baseline  shall  include  the  verification  that  the  Functional  Baseline 
meets  the  requirements  for  all  TAD  systems  and  major  upgrades.  NSWCDD  is  responsible  for 
certifying  to  PEO(TAD)  that  the  Functional  Baseline  is  consistent  with  the  approved  Conceptual 
Performance  Baseline  and  satisfies  the  mission  need  with  a  design  that  is  balanced  in  cost  and 
performance  for  the  specified  need  date.  As  the  Systems  Development  Engineer,  NSWCDD  has 
lead  government  responsibility  for  the  development  of  the  Allocated  Baseline  for  all  TAD 
systems  and  major  upgrades.  NSWCDD  has  lead  responsibility  for  government  oversight 
deemed  necessary  by  the  Program  Manager  for  government  acceptance  of  the  product  baseline. 
In  this  capacity,  NSWCDD  is  responsible  for  certifying  to  the  PEO  that  the  Allocated  Baseline 
fully  implements  the  requirements  of  the  Functional  Baseline  and  satisfies  mission  need  while 
maintaining  cost  and  performance  balance  and  schedule.  NSWCDD  will  have  a  major 
supporting  role  in  the  development  of  new  system  concepts  and  technologies,  as  well  as  a 
supporting  role  in  the  development  of  the  Conceptual  Performance  and  Functional  Baselines. 

1.5. 1.4  TAD  Program  Manager 

Individual  PMs  are  responsible  for  planning  and  budgeting  all  phases  of  engineering.  The 
assigned  TAD  Systems  Engineer  is  responsible  to  the  PM  for  performance,  cost  and  schedule 
management  of  systems  engineering  and  to  TAD-SE  for  compliance  with  technical  policy  and 
requirements.  The  PM  is  responsible  for  the  technical  integrity  of  the  system  throughout  the 
system  life,  for  selection  between  technically  acceptable  design  alternatives  and  determination  of 
the  degree  of  acceptable  risk.  Program  Managers  are  encouraged  to  identify  and  implement 
specific  system  engineering  taskings  in  concert  with  this  policy. 
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1.5.2  Management  Structure  for  Plan  Implementation 

A  high-level  diagram  of  the  management  structure  for  execution  of  this  NTW  system 
requirements  engineering  plan  is  shown  in  Figure  1-2. 

1.5.2.1  NTW  Program  Management  Team 

An  NTW  Program  Management  Team  will  be  formed  to  provide  top  level  program 
manager  guidance.  PMS  452  will  lead  NTW  Program  Management  Team  with  team  members 
shown  in  Table  1-1 .  The  responsibilities  of  the  NTW  Program  Management  Team  are  to: 

•  Provide  program  planning  and  direction; 

•  Provide  funding; 

•  Resolve  conflicts  of  interests  and  competing  priorities; 

•  Conduct  independent  reviews; 

•  Provide  program  assessment  and  recommendations  to  higher  level  leadership; 

•  Provide  program  coordination  with  the  Defense  Acquisition  Board  (DAB);  and 

•  Obtain  DAB  documentation  approval. 


1-10 


NSWCDD/MP-99/12 


1-11 


AS  NECESSARY 


NSWCDD/MP-99/12 


1. 5.2.2  NTW  System  Engineering  Team 

A  NTW  System  Engineering  Team  (SET)  will  be  formed  which  will  be  responsible  for 
the  allocation  and  management  of  cost  and  schedule  milestones  and  exit  criterion  to  the  Systems 
Concept  Engineer  and  Systems  Development  Engineer  based  upon  the  agreed  allocations  from 
PMS  452.  The  PMS  452  System  Engineer  will  lead  the  SET  with  Team  members  as  shown  in 
Table  1-1.  Some  of  the  tasks  that  the  SET  would  be  chartered  to  perform,  but  not  limited  to,  are: 

•  Coordinate  development,  review  and  approval  of: 

-  ORD  and  SRD; 

-  SEMP; 

-  Mission  requirements  and  design; 

-  Risk  reduction;  and 

-  System  Design  Reviews. 

•  Provide: 

-  Program  integration; 

-  Ship  combat  system  engineering  input; 

-  DAB  support; 

-  Technology  transition  plan;  and 

—  Coordination  with  external  organization  functions. 

1. 5.2.3  Product  IPTs 


Depending  upon  the  specific  situation,  the  SET  will  charter  a  number  of  mission  product 
IPTs  that  will  be  charged  with  the  responsibility  of  managing  the  development  o  fits  specific 
area.  These  areas  might  include  ship  combat  system  engineering  design,  BMC4I,  missile  system 
design,  threat  definition  or  T&E.  These  IPTs  would  be  chaired  by  Product  SET  and  would 
typically  include  the  following  members: 


•  PMS  422 

•  PMS  410 

•  PEO  SC 

•  JHU/APL 


•  NSWCDD 

•  MIT/LL 

•  Mission  Area 
engineer 


•  SEA&I  contractor 

•  System  design 
contractor 
representative 
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Some  of  the  tasks  that  these  DPTs  would  be  chartered  to  perform,  but  not  limited  to,  are: 

•  Coordinate  development,  review  and  approval  of: 

Ship  system  engineering  (including  all  subsystem  elements,  i.e.,  combat  system, 
BMC4I,  etc.) 

-  Threat  definition 

-  TEMP 

-  Right  test  plans 
Failure  analyses 

-  TLRs 

-  PIDS 

.  -  CM  plan  for  a  Cl 

1.5. 2.4  PEO(TAD)  system  Engineer  -  Plan  Execution  Responsibilities 

The  PEO(TAD)  Systems  Engineer,  (TAD)-SE,  has  the  general  systems  engineering 
responsibilities  discussed  in  1.4. 1.1.  The  PEO(TAD)-SE  responsibilities  for  the  execution  of  this 
plan  are  as  follows: 

•  Be  a  member  of  the  NTW  Program  Management  Team;  and 

•  Be  responsible  for  the  executive  oversight  of  the  TAD  system  engineers  for  the 
execution  of  this  plan.  This  oversight  responsibility  encompasses  the  PMS  452 
System  Engineer  as  well  as  the  NTW  effected  TAD  product  program  system 
engineers. 

1. 5.2.5  PMS  452  and  PMS  452  System  Engineers  -  Plan  Execution  Responsibilities 

PMS  452  and  his  system  engineers  support  this  system  requirements  engineering  process 
as  follows: 


•  PMS  452  will  lead  the  NTW  Program  Management  Team; 

•  Provides  Mission  Program  guidance; 

•  Leads  the  formal  reviews  of  the  plan  execution  including  the  Operational 
Requirements  Review,  (ORR),  Conceptual  Performance  Baseline  Review,  (CPBR), 
and  Mission  System  Requirements  Review  (MSRR); 

•  NTW  System  Engineer  leads  the  System  Engineering  Team; 

•  Be  a  member  of  the  Step  0  Work  Group; 

•  Be  a  member  of  the  Step  1  Engineering  Work  Group; 

•  Be  a  member  of  the  Step  2  Work  Group; 

•  Be  a  member  of  the  Step  3  Work  Group;  and 

•  Be  a  member  of  the  Step  4  Work  Group. 
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1.5.2. 6  JHU  /  APL  -  Plan  Execution  Responsibilities 

JHU/APL  as  the  PEO(TAD)  Conceptual  Systems  Engineer  has  the  general  systems 
engineering  responsibilities  addressed  in  1.4. 1.2.  The  JHU/APL  responsibilities  for  the 
execution  of  this  plan  are  as  follows: 

•  Be  a  member  of  the  NTW  Program  Management  Team; 

•  Be  a  member  of  the  NTW  System  Engineering  Team; 

•  Leads  the  Step  0  (Operational  Needs  and  Requirements)  Work  Group; 

•  Leads  the  Step  1  (Define  the  Operational  Environment)  Engineering  Work  Group; 

•  Leads  the  Step  1  Operational  Work  Group; 

•  Leads  the  Step  2  (Define  System  Boundaries)  Work  Group; 

•  Co-leads  the  Step  3  (ID  System/Subsystem  Attributes)  Work  Group  with  NSWCDD; 

•  Co-leads  the  Step  4  (Establish  the  Allocated  Baseline)  Work  Group  with  NSWCDD; 

•  Leads  the  development  of  the  Conceptual  Performance  and  Functional  Baselines; 

•  Be  responsible  for  certifying  to  PEO(TAD)  that  the  Conceptual  Performance  Baseline 
is  consistent  with  the  operational  requirements; 

•  Be  responsible  for  certifying  to  PEO(TAD)  that  the  Functional  Baseline  is  consistent 
with  the  approved  Conceptual  Performance  Baseline; 

•  Participate  in  the  ORR,  CPBR  and  MSRR  formal  reviews. 

1. 5.2.7  NSWCDD  -  Plan  Execution  Responsibilities 

NSWCDD  as  the  PEO(TAD)  Systems  Development  Engineer  has  the  general  systems 
engineering  responsibilities  addressed  in  1.4.1. 3.  The  NSWCDD  responsibilities  for  the 
execution  of  this  plan  are  as  follows: 

•  Be  a  member  of  the  NTW  Program  Management  Team; 

•  Be  a  member  of  the  NTW  System  Engineering  Team; 

•  Co-leads  the  Step  3  (ID  System/Subsystem  Attributes)  Work  Group  with  JHU/APL; 

•  Co-leads  the  Step  4  (Establish  the  Allocated  Baseline)  Work  Group  with  JHU/APL; 

•  Be  responsible  for  the  acceptance  of  the  Functional  Baseline  which  includes 
verification  that  the  Functional  Baseline  meets  the  operational  requirements  and 
Conceptual  Performance  Baseline; 

•  Leads  government  responsibility  for  the  development  of  the  NTW  Allocated 
Baseline; 

•  Provides  a  major  supporting  role  in  the  execution  of  the  following  steps  as  well  as 
membership  in  the  work  groups: 

-  Step  0  (Identify  Operational  Needs  and  Requirements)  Work  Groups; 

-  Step  1  (Define  the  Operational  Environment)  Operational  Work  Group  and 
Engineering  Work  Group; 

-  Step  2  (Define  the  System  Boundaries)  Work  Group;  and 

•  Participates  in  the  ORR,  CPBR  and  MSRR  formal  reviews. 
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1.5.2.8  PEO(TAD)  and  PEO  SC  Product  Program  Managers  -  Plan  Execution 
Responsibilities 

The  product  program  managers  have  the  general  systems  engineering  responsibilities 
addressed  in  1.4. 1.4.  The  product  program  managers  and  their  system  engineers  support  this 
system  requirements  engineering  process  as  follows: 

•  Be  a  member  of  the  NTW  Program  Management  Team; 

•  Be  a  member  of  the  NTW  System  Engineering  Team; 

•  Be  a  member  of  the  Review  Panel  at  ORR,  CPBR  and  MSRR; 

•  Be  a  member  of  the  Step  0  Work  Group; 

•  Be  a  member  of  the  Step  1  Engineering  Work  Group; 

•  Be  a  member  of  the  Step  2  Work  Group; 

•  Be  a  member  of  the  Step  3  Work  Group;  and 

•  Be  a  member  of  the  Step  4  Work  Group. 

1.5. 2.9  System  Requirements  Engineering  Groups 

Step  0  Work  Group  -  A  requirements  work  group  of  personnel  from  JHU/APL, 
NSWCDD  and  other  technical  organizations  listed  in  Table  1-1  will  be  responsible  for  the 
collation  and  reconciliation  of  the  NTW  operational  requirements  and  needs.  The  Requirements 
Work  Group  will  be  the  primary  forum  for  reconciliation  of  the  requirements  and  oversight  of 
the  generation  of  the  traceability  matrix.  The  Step  0  Work  Group  will  be  led  by  JHU/APL  and 
supported  by  NSWCDD. 

Step  1  Work  Groups  -  Two  work  groups  will  be  established  to  support  different  aspects 
of  the  operational  environment  definition.  The  participants  of  each  work  group  are  listed  in 
Table  1-1.  The  work  groups  have  representation  from  many  of  the  same  organizations,  but  the 
type  of  expertise  is  quite  different.  Each  work  group  will  report  to  the  overall  Step  Lead, 
JHU/APL,  who  will  be  responsible  for  coordinating  issues  and  recommendations  between  Work 
Groups  and  incorporating  the  recommendations.  NSWCDD  will  support  JHU/APL  on  this 
effort. 


The  Operational  Work  Group  will  be  comprised  of  warfighters  and  personnel  with 
experience  in  fleet  operations.  The  Operational  Work  Group  will  provide  guidance  and  review 
of  the  operational  situations  to  ensure  that  they  represent  how  the  forces  would  be  deployed  and 
operate. 

The  Engineering  Work  Group  will  be  comprised  of  TAD  analysts  and  design  experts.  It 
will  provide  a  preliminary  set  of  threat  and  environmental  characteristics  that  stress  each  aspect 
of  the  NTW  System.  The  Engineering  Work  Group  also  will  be  responsible  for  reviewing  the 
documentation  of  resulting  situations  to  ensure  that  information  required  for  modeling  and 
evaluation  in  Steps  3  and  4  is  included. 
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Step  2  Work  Group  -  To  ensure  that  the  functionality  of  current  and  future  NTW 
subsystems  are  captured,  representatives  from  the  nomenclatured  system  technical  community 
will  participate  in  the  development  of  the  functional  descriptions  developed  in  this  step.  A  series 
of  working  groups  made  up  of  NSWCDD,  JHU/APL,  TAD  systems  engineering  personnel, 
representatives  from  the  nomenclatured  systems  under  consideration  and  other  personnel  listed 
in  Table  1-1  will  be  utilized  to  ensure  both  a  consistency  of  approach  and  depth  and  accurate 
capturing  of  current  and  future  system  functionality  and  interfaces.  The  Step  2  Work  Group  will 
be  led  by  JHU/APL  and  supported  by  NSWCDD. 

Step  3  Work  Group  -  A  work  group  will  be  formed  which  will  be  responsible  for  the 
development  of  the  NTW  Conceptual  Performance  Baseline.  This  work  group  will  identify 
system  attributes,  functions,  and  success  criteria  to  be  used  in  the  development  of  the  functional, 
performance,  and  cost  requirements  for  NTW.  The  Step  3  Work  Group  will  be  co-led  by 
JHU/APL  and  NSWCDD  and  supported  by  representatives  listed  in  Table  1-1. 

Step  4  Work  Group  -  A  work  group  comprised  of  personnel  from  NSWCDD, 
JHU/APL,  PEO(TAD)-SE,  effected  program  managers  and  systems  engineers,  and  other 
personnel  identified  in  Table  1-1  will  be  utilized  during  this  step  to  provide  guidance,  oversight 
and  detailed  planning  for  the  development  of  the  functional  and  allocated  baselines  for  future 
NTW.  The  work  group  will  play  a  key  role  in  defining  the  alternatives  to  be  considered  and 
selecting  alternatives  for  detailed  analysis  and  further  consideration.  The  work  group  will  review 
the  final  recommended  alternative  and  supporting  analyses  to  ensure  all  relevant  issues  have 
been  considered  and  that  it  supports  the  operational,  performance,  and  mission  success  criteria 
that  have  been  established  in  earlier  steps.  The  Step  4  Work  Group  will  be  co-led  by  JHU/APL 
and  NSWCDD. 


1.5.3  Technical  Reviews 

Figure  1-5  illustrates  the  PEO(TAD)-SE  common  process  with  emphasis  on  the  three 
formal  reviews. 

•  The  Operational  Requirements  Review  (ORR)  will  be  held  after  completion  of  Steps 
0,  1  and  2  to  obtain  concurrence  that  the  initial  requirements,  evaluation  environment 
and  understanding  of  the  systems  involved  are  adequate  to  proceed  with  the 
identification  of  the  key  system  attributes  and  top-level  performance  requirements  in 
Step  3. 

•  The  Conceptual  Performance  Baseline  Review  (CPBR)  will  be  held  to  present  the 
options,  risks  and  recommendations  for  the  functional  and  performance  requirements 
for  approval  prior  to  Step  4  allocation. 

•  The  Mission  System  Requirements  Review  (MSRR)  for  NTW  will  be  held  to  obtain 
approval  of  the  recommended  NTW  baseline  and  the  proposed  migration  path. 

The  exit  criteria  for  the  reviews  will  be  the  approval  of  the  information  required  at  the 
review  and  the  completion  of  the  step  documentation.  Additional  details  on  the  information 
presented  at  each  review  and  the  required  documentation  is  provided  in  the  description  of  each 
step  in  Section  II  and  the  list  of  deliverables  in  Section  III. 
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+  The  Allocated  Baseline  in  this  case  is  documented  in  the  SRD  which  the  respective  Program  Offices  will  use  to  develop  their  combat  system  products. 


Figure  1-5.  Reviews  for  the  System  Requirements  Engineering  Process 

1.5.4  Internal/External  Organizations 

A  number  of  Navy  and  external  agencies  may  have  important  roles  in  the  NTW  program. 
Surface  Navy  agencies  including  SECNAV,  OPNAV  and  the  systems  commands  will  have 
significant  roles  in  shaping  a  Navy-wide  approach  to  NTW.  Agencies  external  to  the  Navy, 
including  JTAMDO  and  BMDO,  will  have  significant  roles  in  shaping  a  joint  warfighting  system 
for  TBMD.  The  PEO(TAD)-SE  organization  and  system  requirements  engineering  process  is 
expected  to  establish  and  maintain  appropriate  interfaces  with  each  of  these  agencies.  Key 
agencies  and  their  expected  participation  in  NTW  requirements  definition  and  technical  review 
activities  are  shown  in  Table  1-1 .  Industry  will  be  included  in  Step  4  as  part  of  this  process. 


1.5.5  Customers 

Customers  are  the  reason  the  products  of  the  system  requirements  engineering  process 
exist,  and  as  such,  are  an  essential  element  of  those  processes.  The  systems  engineers,  analysts 
and  technical  experts  will  determine  the  performance,  cost  and  schedule  requirements  at  the  top 
level.  The  primary  customers,  the  end  users,  require  reliable  effective  solutions  to  operational 
problems  that  are  balanced  with  cost  and  schedule.  The  immediate  customers,  the  program 
managers,  continue  to  refine  performance,  cost  and  the  schedule  constraints  throughout  the 
development  process  in  an  effort  to  field  successful  products  to  these  end  users.  The  end  user 
must  understand  the  capabilities,  limitations,  design  and  detailed  workings  of  the  systems  to  be 
built,  since  they  must  eventually  use,  maintain,  and  even  enhance  the  delivered  system.  This 
plan  engages  the  participation  of  a  number  of  Navy  and  external  agencies  as  delineated  in 
Section  1.4.4. 
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1.6  BLK I  SRD 

As  described  in  the  Program  Overview,  NTW  is  envisioned  as  an  evolutionary 
development  with  the  early  deployment  evolved  from  a  modified  ALI,  designated  BLK  I,  on  the 
path  to  a  full  tactical  capability,  designated  BLK  II.  BLK  I  is  driven  by  schedule  and  risks,  i.e.,  a 
mandate  for  deployment  as  early  as  feasible  to  provide  a  limited  capability  against  a  portion  of 
the  threat  and  minimum  technical  risks  to  accommodate  the  schedule.  Because  the  planned 
deployment  of  BLK  I  is  early  in  the  next  decade,  the  functional  and  allocated  baselines  need  to 
be  established  by  the  second  quarter  of  FY  98. 

To  support  this  effort  an  SRD  for  the  BLK  I  will  be  developed  in  parallel  with  the 
structured  system  requirements  engineering  process  for  the  full  NTW  capability.  This  BLK  I 
SRD  will  not  employ  the  rigorous  engineering  process  described  in  the  remainder  of  this 
document.  Rather,  the  SRD  will  be  developed  with  design  fixed  by  allowable  modifications  of 
the  ALI  and  accompanying  elements.  The  resulting  capability  will  be  mapped  to  the  threat  set 
corresponding  to  the  performance  of  the  BLK  I.  The  schedule  for  the  development  of  the  BLK  I 
SRD  is  shown  in  Figure  1-6. 


Figure  1-6.  NTW  System  Requirements  Engineering  Summary  Schedule 
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1.7  SCHEDULE 

The  schedule  for  this  requirement  plan’s  execution  is  driven  by  the  need  to  support  the 
input  for  NTW  in  POM  00.  Although  Figure  1-2  shows  the  system  requirements  engineering 
process  being  sequential  steps,  the  first  three  steps  will  be  executed  essentially  in  parallel.  This 
will  enable  the  interaction  and  passing  of  information  generated  in  the  various  steps.  The 
interaction  between  the  steps  is  detailed  in  the  step  description  in  Section  II  and  the  detailed 
schedule  in  Section  III.  This  parallel  step  execution  will  reduce  the  amount  of  reiteration 
required  and  enable  the  execution  of  the  overall  process  within  one  year.  In  addition  to  the 
parallel  start  of  the  early  steps,  the  preparations  of  the  modeling  and  simulation  facilities  and 
tools  for  Steps  3  and  4  will  commence  at  the  initiation  of  the  overall  plan. 
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SECTION  2.0  -  SYSTEM  REQUIREMENTS  ENGINEERING 

PROCESS 

This  section  describes  the  technical  approach  and  the  system  requirements  engineering 
process  as  applied  to  NTW. 


2.1  INTRODUCTION 

As  discussed  in  Section  I,  Theater  Air  Warfare  systems  engineering  involves  a  hierarchy 
of  systems.  Systems  at  any  one  level  are  embedded  in  successively  higher  level  systems  that 
address  discrete  operating  tasks,  mission  areas,  and  ultimately  joint  operating  forces.  Therefore, 
NTW  can  be  viewed  as  an  integrated  system  which  is  comprised  of  all  Surface  Navy  related 
NTW  resources  and  their  interfaces.  This  NTW  System,  or  capability,  is  made  up  of  various 
subsystems.  Similarly,  the  NTW  “System”  is  a  subsystem  of  the  broader  Navy  TBMD,  Joint 
TBMD  and  Theater  Air  Warfare  “system  of  systems”.  The  primary  product  of  this  system 
requirements  engineering  process  is  an  NTW  SRD.  The  SRD’s  development  will  be  discussed 
in  the  introductory  technical  approach  as  well  as  where  appropriate  in  each  of  the  process  steps. 


2.2  SYSTEM  REQUIREMENTS  ENGINEERING  TECHNICAL  APPROACH 


The  system  requirements  engineering  process  technical  approach  is  the  tailored 
application  of  classical  systems  engineering  concepts  specifically  to  meet  the  needs  of  NTW. 


The  system  requirements  engineering  technical  approach  described  below  is  founded  on 
lessons  learned  over  the  past  decades.  At  the  top-level  and  at  every  intermediate  level,  the 
approach  requires  the  identification  of  inputs,  required  outputs,  and  the  processes  necessary  to 
produce  the  outputs.  The  approach  is  shown  below  in  Figure  2-1. 


Inputs:  As  shown  in  the  adjacent  figure, 
the  NTW  system  requirements  engineering 
approach  starts  with  the  identification  of 
inputs.  For  NTW  system  requirements 
engineering,  they  are:  _ 


•  PMS  452  guidance; 


Current  NTW  requirements; 


Figure  2-1.  PEO(TAD)-SE  General 


•  Projected  force  structure; 

•  DPG/Warfighter  inputs; 

•  Current  and  projected  threats; 
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•  Natural  and  man-made  environment  (including  electromagnetic  effects)  in  which  the 
NTW  System  must  operate; 

•  Available  state-of-the-art  technology  and  technology  trends; 

•  Results  of  TBMD  COEAs; 

•  JTAMDO  analysis; 

•  Results  of  other  TBMD  studies/analyses;  and 

•  Analysis  tools  (e.g.  M&S). 

Outputs:  Outputs  are  the  next  actions  identified.  The  outputs  are  defined  early,  as  they 
determine  the  required  inputs  and  dictate  processes.  The  NTW  system  requirements  engineering 
outputs  consist  of; 

•  NTW  Functional  Baseline,  System  Architecture  and  Allocated  Baseline  which  will  be 
documented  in  the  SRD; 

•  Final  recommended  NTW  System  Requirements  Document; 

•  Migration  Path  Report  describing  how  to  achieve  the  NTW  baseline; 

•  Non-NTW  Systems  Interface  Requirements  Recommendation  Report; 

•  Naval  TBMD  ORD  recommendations; 

•  Technology  Development  Requirements  Report; 

•  Interface  Sensitivity  Analysis  Report; 

•  Risk  Reduction  Prioritization  Report;  and 

•  Design  Reference  Mission. 

The  final  element  is  defining  the  processes  required  to  take  the  input  and  perform  the 
actions,  which  are  required  to  deliver  the  desired  output.  PEO(TAD)-SE  has  developed  a 
common  system  requirements  engineering  process  which  is  described  in  Reference  (a).  This 
process  has  been  tailored  for  NTW  and  is  described  in  Section  2.2.  Each  of  the  steps  must 
remain  under  continuous  scrutiny  for  iterative  improvement  as  the  plan  for  system  requirements 
activities  is  executed.  PEO(TAD)-SE’s  system  requirements  engineering  technical  approach  for 
NTW  is  shown  in  Figure  2-2. 
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Figure  2-2.  NTW  System  Requirements  Engineering  Technical  Approach 


2.2.1  System  Requirements  Engineering  Process  Tool  Selection 

To  facilitate  the  large  amount  of  information  that  needs  to  be  collected  and  analyzed,  a 
systems  engineering  tool  or  set  of  tools  will  be  selected.  These  tools  are  computer  programs  and 
databases  designed  to  support  and  track  data  collected  and  developed  during  the  system 
requirements  engineering  process.  This  systems  engineering  tool  does  not  include  performance 
and  cost  modeling  and  simulation.  See  Sections  2.1.2  and  2.6.3  for  a  discussion  of  modeling  and 
simulation  tools.  It  will  be  a  goal  to  select  a  tool  that  will  be  compatible  with  lower  level  NTW 
systems  development  tools.  The  systems  engineering  tools  must  provide  the  following 
capabilities: 

•  Traceability  of  top  down  requirements  and  functions; 

•  Extraction  of  requirements  and  descriptions  from  existing  documentation; 

•  Building  of  functional  and  physical  hierarchical  models  and  provide  mapping 
between  the  models; 

•  Modeling  of  control  features  as  well  as  data  flow; 

•  Analysis  of  interfaces;  and 

•  Generation  of  reports  which  are  compatible  with  standard  word  processing  and 
graphics  tools. 
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Candidate  systems  engineering  tools  are: 


Tool 

Company 

RDD-100 

Ascent  Logic  Corp. 

Product  Track 

Cimflex  Tecknowledge  Corp. 

Vital  Link 

Compliance  Automation,  Inc. 

RTM 

Marconi  Systems  Tech. 

Cradle  SEE 

Mesa  Systems  Guild,  Inc. 

Spec  Writer 

PRC,  Inc. 

SLATE 

TD  Technologies 

Require 

Unisys  Corp. 

CORE 

Vitech  Corp. 

DOORS 

Quality  Systems  Software  (QSS)  Corp. 

CASETS 

Boeing 

2.2.2  Modeling  and  Simulation  Tool  Selection 

To  assess  system  performance,  it  is  necessary  to  use  modeling  and  simulation  tools. 
Several  different  types  of  models  (in  particular  cost  and  performance  models)  may  be  needed  to 
address  the  entire  system.  Critical  functions  and  attributes  will  need  to  be  analyzed  to  identify 
the  most  cost  effective  and  highest  performance  system.  Section  2.6.3  addresses  the  modeling 
strategy  needed  to  select  the  proper  modeling  and  simulation  tools. 


2.2.3  Communications 

The  use  of  templates  for  select  elements  of  the  system  requirements  engineering  process 
can  greatly  aid  the  systems  engineer  to  ensure  commonality  of  process  and  resulting  products. 
The  template,  as  well  as  guidelines  for  its  use,  will  be  maintained  in  an  electronic  program 
library.  To  this  end,  TAD  will  use  the  following  documentation  template  for  the  communication 
of  system  requirements  engineering  results: 

•  Systems  Engineering  Memorandum  (SEM).  The  SEM  will  be  the  prevalent  template 
used  across  the  program.  All  documentation  associated  with  technical  baseline 
development,  modification  including  cost  and  schedule,  trade  studies,  risk 
assessments  or  verification  will  be  attached  or  documented  in  the  SEM. 

Additional  templates  may  be  used  if  warranted  as  the  system  requirements  engineering 
process  is  executed. 
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2.2.4  Documentation  of  Results 

Documentation  management,  process  documentation  and  configuration  control  are 
important  activities  in  traditional  systems  engineering  and  are  ever  more  crucial  in  Integrated 
Product/Process  Development  (BPPD)  implementation.  The  concurrency  of  efforts,  the 
numerous  tradeoffs  being  conducted  and  successive  prototypes  under  investigation  make  the 
documentation  process  an  integral  part  of  EPPD  implementation.  The  primary  product  of  the 
system  requirements  engineering  effort  described  in  this  plan  is  the  SRD.  The  process  for  the 
SRD’s  development  is  illustrated  in  Figure  1-3.  The  details  on  other  documents  and 
configuration  management  baselines  are  addressed  in  each  step  of  the  system  requirements 
engineering  process. 


2.3  THE  NTW  SYSTEM  REQUIREMENTS  ENGINEERING  PROCESS 

The  NTW  system  requirements  engineering  process  to  be  used  is  a  six  step  common 
process  culminating  in  the  identification  of  the  NTW  baseline  requirements  (System 
Requirements  Document),  interface  requirements  recommendations  for  non-NTW  systems 
contributing  to  the  NTW  mission,  definition  of  migration  path,  identification  of  technology 
development  requirements,  and  production  of  analysis  reports  on  which  the  Navy’s  senior 
leadership  can  concur  and  support  POM  planning. 

PEO(TAD)-SE  has  developed  a  common  system  requirements  engineering  process.  This 
process  is  initiated  by  the  capture  of  the  mission  requirements,  which  has  been  included  as  Step  0 
in  this  plan.  Each  step  has  been  summarily  decomposed  into  its  respective  sub-processes  and  is 
described  in  Sections  2.3  through  2.8  of  this  plan.  Decomposition  of  each  step  follows  the  model 
described  previously  in  that  inputs,  processes  and  outputs  are  identified  for  each  step.  At  the  top- 
level  as  well  as  at  each  sub  level  (step)  the  processes  need  to  be  flexible,  responsive,  and 
designed  with  control  points  to  measure  effectiveness. 

The  six  system  requirements  engineering  steps  followed  by  this  plan  are: 


•  Step  0:  Identify  operational  needs  and  requirements; 

•  Step  1 :  Define  the  operational  environment  in  which  NTW  will  perform; 

•  Step  2:  Define  the  system’s  boundaries; 

•  Step  3:  Identify  NTW  system/subsystem  key  attributes; 

•  Step  4:  Establish  the  NTW  Functional/Allocated  Baselines;  and 

•  Step  5:  Conduct  a  Mission  System  Requirements  Review  (MSRR)  for  NTW. 


The  Allocated  Baseline  is  documented  in  the  SRD,  which  the  respective  Program  Offices  will  use  to 
develop  their  combat  system  products. 
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As  shown  in  Figure  2-3,  the  system  requirements  engineering  process  is  not  a  single  pass 
action.  Each  step  can  identify  new  items  required  from  previous  steps,  creating  feedback 
through  an  interactive  looping  action. 


2.3.1  NTW  SRD  Development  Overview 

A  primary  product  of  the  NTW  system  requirements  engineering  process  is  an  SRD.  The 
SRD  will  address  multiple  requirements  levels  from  the  operational  requirements  at  the  Navy 
TBMD  Mission  Area,  the  NTW  Mission  Program  and  finally  to  the  product  programs.  This 
process  is  illustrated  in  Figure  2-4  which  shows  the  development  of  each  section  of  the  SRD  at 
each  step  in  the  process  as  well  as  the  formal  reviews.  While  Figure  2-4  shows  the  SRD 
generically,  the  SRD  will  be  developed  to  conform  to  the  SRD  format  being  developed  by 
PEO(TAD)-SE. 
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Figure  2-3.  NTW  System  Requirements  Engineering  Process 
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Figure  2-4.  Development  of  the  NTW  Initial  Draft  SRD 
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2.4  STEP  0  -  IDENTIFY  OPERATIONAL  NEEDS  AND  REQUIREMENTS 

The  purpose  of  this  step  in  the  system  requirements  engineering  process  is  to  collate  and 
reconcile  the  top-level  operational  requirements  and  needs  tor  NTW  and  the  associated 
requirements  for  the  systems  involved. 

Until  recently,  TBMD  requirements  had  been  governed  by  the  Joint  Requirements 
Oversight  Committee  (JROC)  approved  Capstone  Operational  Requirements  Document  (ORD), 
dated  9  Dec  1994.  The  Capstone  ORD  was  comprised  of  both  TBMD  (Part  I)  and  National 
Missile  Defense  and  Global  Defense  (Part  II).  In  late  FY96,  the  decision  for  the  document  to  be 
divided  by  distinct  mission  areas  resulted  in  re-evaluation  of  the  purpose  and  content.  Presently, 
the  draft  of  the  new  Theater  Missile  Defense  (TMD)  Capstone  Requirements  Document  (CRD) 
includes  all  operational  elements  of  theater  missile  defense  -  passive  defense;  active  defense; 
attack  operations  and  Command,  Control.  Communications,  Computers  and  Intelligence  (C  I). 
A  change  in  the  philosophy  now  applies  the  document  to  TBMD,  Cruise  Missile  Defense  (CMD) 
and  Anti-Ship  Missile  Defense  (ASMD).  The  CRD  identifies  the  overarching  requirements  for  a 
family  of  theater  missile  defense  systems  to  protect  US  forces,  our  allies,  coalition  forces,  and 
critical  assets  in  the  theater  against  missile  attacks.  It  is  intended  to  guide  the  services  in 
developing  operational  requirements  documents  for  future  theater  missile  defense  systems  and  to 
facilitate  development  of  interoperable  systems.  It  will  also  provide  a  vehicle  for  the  JROC  to 
maintain  oversight  of  the  services'  TMD  programs.  A  formal  coordination  process  is  under  way 
with  a  draft  released  for  review  in  July  FY97,  Senior  Warfighter  Review  in  July  FY97  and 
submission  to  JROC  for  approval  in  fourth  quarter  FY97.  Similarly,  the  Naval  TBMD  ORD 
(dated  17  July  1996)  is  being  revised  to  include  the  critical  parameters  for  the  NTW  system 
which  are  incomplete  in  the  current  version.  The  anticipated  schedule  is  for  a  draft  to  be 
submitted  to  JROC  for  approval  during  fourth  quarter  of  FY97. 

Figure  2-5  illustrates  the  existing  top-level  requirement  documentation  flow,  starting  with 
the  TMD  Capstone  requirements  and  threats,  and  the  organization  of  the  NTW  operational 
requirements  and  needs  into  a  coherent  hierarchical  structure.  It  also  illustrates  that  after  initial 
identification,  the  requirements  will  be  modified  via  feedback  as  the  other  system  requirements 
engineering  steps  are  performed. 


2-9 


TBMD  REQUIREMENTS  DOCUMENTS 


NSWCDD/MP-99/12 


2-10 


Figure  2-5.  Identify  Operational  Needs  and  Requirements 
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Step  0  is  intended  to  help  answer  the  following  fundamental  questions  to  set  the  stage  for 
the  subsequent  steps: 

•  What  are  the  existing  operational  requirements,  both  Navy  and  Joint? 

•  What  are  the  relationships  between  these  requirements? 

•  What  are  the  missing  or  conflicting  decompositions  from  the  top-level  operational 
requirements? 

•  What  are  the  affordability  constraints  that  will  bound  the  NTW  solution?  and 

•  What  are  reasonable  inputs  to  the  NTW  Operational  Requirements  Document? 

Figure  2-6  diagrams  the  process  that  will  be  used  to  answer  the  previous  questions. 


Figure  2-6.  Identify  Operation  Needs  and  Requirements  Process 
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2.4.1  Step  0  Inputs 

•  PMS  452  Guidance  -  General  guidance  will  be  provided  by  PMS  452. 

•  Existing  Requirements  -  The  primary  input  to  Step  0  is  the  existing  and  projected  top- 
level  mission  needs  and  operational  requirements  documentation  derived  from 
previous  DoD,  BMDO,  and  Navy  studies  and  analyses.  Core  NTW  systems  are  listed 
in  Table  2-1  of  Section  2.5.2. 

•  Threats  -  Threat  information  will  be  collected  from  multiple  sources.  The  TMD 
Capstone  Documents,  Operational  Requirements  Documents  (ORDs)  and  System 
Threat  Assessment  Reports  (STARs)  will  be  the  primary  source  for  general  threat 
information  More  detailed  threat  information  will  be  obtained  and  coordinated  with 
the  recently  formed  PEO(TAD)  and  PEO  SC  Threat  Cell  and  with  the  Joint  Guidance 
and  Policy  Paper  (JG&PP)  #97-01. 

•  Feedback  -  Step  0  documents  an  initial  set  of  operational  requirements  and  establishes 
traceability.  These  requirements  will  be  modified  and  further  defined  by  Step  2  as  the 
NTW  boundaries  are  better  defined  by  Step  3  as  the  key  requirements  are  determined 
and  finally  by  Step  4  as  the  requirements  are  allocated. 


2.4.2  Gather  the  Known  Requirements 

Over  the  past  several  years  the  NTW  operational  requirements  were  derived  from  the 
Capstone  Operational  Requirements  Document  (ORD)  which  was  preceded  by  the  Mission 
Needs  Statements  (MNS)  for  TMD  and  Sea-Based  TBMD.  As  stated  in  the  introduction  the 
Capstone  ORD  (now  the  Capstone  Requirements  Document)  and  Naval  TBMD  ORD  are  being 
reevaluated  and  new  drafts  are  expected  by  the  end  of  FY97.  In  addition  to  the  official 
documentation,  previous  and  ongoing  studies  have  proposed  operational  requirements  for  NTW 
and  even  decomposed  those  to  proposed  operational  requirements  for  the  individual 
nomenclatured  systems.  For  this  effort  all  of  the  official  and  proposed  requirements  documents 
from  overall  mission  area  to  nomenclatured  system  will  be  collected. 

In  addition  to  the  TBMD  operational  requirements,  the  operational  requirements  for  the 
systems  associated  with  NTW  will  also  be  collected.  For  this  effort  the  full  traceability  of  the 
non-NTW  operational  requirements  is  not  required.  The  requirements  are  collected  for  future 
reference  for  Step  2,  3  and  4.  The  list  of  systems  effected  must  be  coordinated  with  Step  2, 
which  defines  the  boundaries  and  associated  systems.  The  legacy  system  operational 
requirements  and  needs  should  be  documented  in  individual  ORDs  or  equivalent  documents  or 
specifications. 


2.4.3  Develop  Operational  Requirements  Traceability  Matrix 

Once  the  NTW  related  requirements  are  collected,  they  will  be  organized  into  an 
Operational  Requirements  Traceability  Matrix  that  shows  the  decomposition,  relationship  and 
allocation  from  the  TBMD  MNS  to  the  Naval  TBMD  ORD.  Requirements  will  fall  into  three 
basic  categories:  quantifiable  performance,  functionality  and  interoperability/compatibility 
constraints.  A  Requirements  Work  Group  of  TBMD  experts  generate  and  manage  the 
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operational  requirements  as  well  as  resolving  conflict  and  identifying  missing  requirements.  The 
Requirements  Work  Group  will  be  led  by  JHU/APL  and  made  up  of  representatives  from  the 
organizations  identified  in  Table  1-1. 

To  facilitate  the  development  of  the  Operational  Requirements  Traceability  Matrix  an 
automated  requirements  tracking  tool  will  be  used.  The  requirements  from  each  of  the  NTW 
related  documents  collected  in  Section  2.3.2  will  be  entered  into  a  database  to  show  the 
relationship  between  elements  and  higher  level  systems.  Each  requirement  will  be  reviewed  to 
determine  the  documented  allocation  and  relationship  to  both  upper  and  lower  level  systems. 


2.4.4  Identify  Missing,  Overlapping,  or  Conflicting  Requirements 

After  the  explicit  allocations  and  relationships  are  identified  from  the  formal 
documentation,  the  entire  Operational  Requirements  Traceability  Matrix  will  be  reviewed  to 
identify  and  highlight  problems  and  weaknesses  which  will  be  addressed  in  later  steps  of  the 
system  requirements  engineering  process.  For  example,  the  requirements  stated  at  the  TBMD 
(mission  area)  or  NTW  (mission  program)  may  not  have  been  allocated  or  decomposed  to  the 
BMC4I  systems  (product  programs)  requirements.  The  more  likely  situation  is  that  the  element 
level  operational  requirements  will  have  numerous  details  that  are  not  directly  upwardly 
traceable.  These  additional  requirements  will  be  evaluated,  not  to  determine  if  the  quantified 
numbers  are  supportable,  but  to  determine  if  they  are  indirectly  decomposed  from  a  higher 
operational  requirement. 

In  addition  to  checking  for  missing  traceability,  the  requirements  will  be  reviewed  for 
redundancies  and  conflicts  as  a  result  of  the  various  studies  decomposing  the  operational 
requirements  differently. 


2.4.5  Propose  Resolution  of  Conflicting  and  Missing  Requirements 

To  finish  the  development  of  the  Operational  Requirements  Traceability  Matrix, 
recommendations  will  be  made  to  resolve  the  issues  raised  in  Section  2.3.4.  It  is  not  the  intent  of 
Step  0  to  perform  detailed  analyses  and  determine  the  final  solution  but  rather  to  provide  a 
reasonable  starting  point  and  document  the  assumptions  that  lead  to  the  recommendations.  As 
part  of  that  documentation  a  list  will  be  developed  of  the  element  interfaces,  functionality  and 
performance  that  need  further  definition  and  analysis.  This  list  will  be  incorporated  in  the 
Steps  2,  3  and  4  studies  and  analyses  as  appropriate  to  verify  and  refine  the  proposed 
requirements. 

The  Requirements  Work  Group  review  will  utilize  a  structured  top-down  process  to 
review  and  assess  the  operational  requirements  and  top-level  functions.  The  Requirements  Work 
Group  will  start  with  the  TBMD  mission  area  and  identify  the  tasks  involved  and  then  further 
develop  a  set  of  operational  requirements  to  perform  the  tasks.  The  results  of  the  structured 
requirements  review  will  provide  insight  into  the  missing  requirements  traceability  and  provide 
recommendations  for  additional  operational  requirements  that  can  be  incorporated  until  the 
detailed  analysis  is  performed  in  Steps  3  and  4. 
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2.4.6  Life  Cycle  Support  Requirements 

To  bound  the  scope  of  the  alternative  analysis  performed  in  Step  4,  the  top-level  support 
requirements  will  be  identified.  Without  some  reasonable  understanding  of  these  constraints 
considerable  effort  could  be  expended  examining  potential  solutions  that  would  ultimately  be 
unsupportable.  For  NTW  it  is  anticipated  that  the  components  of  the  system  will  be  required  to 
operate  and  be  supported  within  the  existing  infrastructure  and  strategy.  This  effort  will  draw 
heavily  on  the  existing  Navy  Area  TBMD  Cost  Analysis  Requirements  Description  (CARD)  and 
the  NTW  CARD  currently  under  development. 


Since  system  support  is  a  key  factor  in  total  system  life  cycle  cost,  the  system  mission 
support  assumptions  will  be  identified.  It  may  be  very  difficult  to  identify  a  single  philosophy 
since  virtually  the  entire  current  system  is  fielded  with  a  support  structure  already  in  place.  At  a 
minimum,  the  following  elements  of  supportability  shall  be  analyzed: 


•  Maintenance  Planning 

•  Facilities 

•  Supply  Support 

•  Support  Equipment 

•  Packaging,  Handling,  Storage  & 
Transportation  (PHS&T) 


•  Training  and  Training  Support 

•  Computer  Resources  Support 

•  Manpower  and  Personnel 

•  Design  Interface 

•  Technical  Data 


2.4.7  Affordability  Constraints 

To  bound  the  study  options  that  need  to  be  considered,  affordability  constraints  will  be 
developed.  The  affordability  of  the  NTW  System  must  be  considered  for  a  defined  system  life. 
Determining  the  total  cost  of  the  system  will  require  more  than  a  simple  tabulation.  For  the 
legacy  systems  involved  in  NTW,  the  primary  sources  of  affordability  information  are  the  POM 
budget  and  the  program  managers.  For  the  new  elements,  the  latest  Navy  plans  and  projections 
will  be  utilized.  The  budgetary  estimates  will  include  not  only  RDT&E  and  SCN  costs  but  an 
estimate  of  the  operational  and  support  costs  once  the  system  is  developed. 


2.4.8  Document  Requirements 

The  operational  requirements  and  needs  will  be  documented  in  the  Operational 
Requirements  Traceability  Matrix  which  will  show  decomposition  from  the  TMD  MNS  and 
TMD  Capstone  Requirement  Document  to  the  Naval  TBMD  ORD. 

An  Operational  Requirements  Report  will  be  a  companion  report  to  the  decomposition 
matrix  and  will  be  written  to  document  the  requirements  issues  that  were  discovered  in  Section 
2.3.4  along  with  the  rationale  and  proposed  resolution  of  the  issues  developed  in  Section  2.3.5. 
The  report  will  also  include  the  life  cycle  support  assumptions  and  affordability  constraints 
developed  in  Sections  2.3.6  and  2.3.7. 
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The  overall  Navy  requirements  are  included  in  the  Naval  TBMD  ORD  which  has 
sections  that  describe  the  overall  Naval  TBMD  system  and  then  further  details  for  the  specific 
systems:  Area,  Marine  Expeditionary  and  Theater  Wide.  The  development  of  the  Operational 
Requirements  Traceability  Matrix  will  provide  insight  into  the  completeness  and  consistency  of 
the  NTW  requirements  and  allow  the  documentation  of  recommended  changes  and  modifications 
to  the  NTW  related  aspects  of  the  Naval  TBMD  ORD.  This  draft  will  only  provide  suggested 
requirements  with  placeholders  for  the  quantitative  parameters.  The  ORD  recommendations  will 
be  updated  at  the  completion  of  Step  3  and  again  after  Step  4. 

The  NTW  Mission  Program  operational  requirements  captured  in  this  step  will  be 
documented  in  draft  sections  of  the  SRD.  The  threats  and  operational  environment  will  also  be 
drafted  for  inclusion  in  the  SRD. 


2,4.9  Operational  Requirements  Review 

At  the  end  of  the  previous  steps  the  result  will  be  a  completed  Operational  Requirements 
Traceability  Matrix  that  documents  the  operational  requirements.  Some  entries  will  be  fully 
documented  and  others  will  simply  be  recommendation  with  loose  rationale.  These  are  not 
intended  to  be  the  final  NTW  requirements  but  merely  representative  and  complete  enough  to 
begin  the  more  rigorous  system  requirements  engineering  analysis. 

At  the  completion  of  Steps  0,  Steps  1  and  2,  an  Operational  Requirements  Review  (ORR) 
will  be  held.  The  Operational  Requirements  Traceability  Matrix  is  the  primary  output  of  Step  0 
that  will  be  presented  at  the  ORR.  The  details  of  the  entire  traceability  matrix  can  not  be 
reviewed  at  the  ORR.  The  ORR  will  focus  on  the  requirements  issues,  proposed  resolutions  with 
supporting  rationale  and  a  discussion  of  the  additional  analysis  required.  The  ORR  will  be  led 
by  PMS  452  and  jointly  hosted  by  JHU/APL  and  NSWCDD.  The  participants  in  the  ORR  are 
identified  in  Table  1-1. 


2.4.10  Step  0  Products 

•  Requirements  Library  -  This  library  will  not  actually  be  a  delivered  product  but  rather 
a  source  for  all  of  the  related  requirements  documents  including  the  requirements 
database.  The  library  will  need  to  be  maintained  and  updated  throughout  the 
remaining  steps; 

•  NTW  Operational  Requirements  Traceability  Matrix; 

•  NTW  Operational  Requirements  Report; 

•  Draft  recommendations  for  the  Naval  TBMD  ORD;  and 

Initial  draft  of  operational  requirements  and  threats  section  of  NTW  SRD. 
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2.5  STEP  1  -  DEFINE  THE  OPERATIONAL  ENVIRONMENT 

The  purpose  of  this  step  is  to  define  the  Design  Reference  Mission  (DRM)  which  details 
the  operational  environment  within  which  the  NTW  system  attributes  and  requirement 
allocations  are  evaluated.  Accurate  and  complete  specification  of  the  DRM  is  required  to 
support  the  evaluation  of  allocation  alternatives  and  relative  importance  of  design  characteristics. 
The  DRM  will  be  the  baseline  used  to  evaluate  the  relative  merit  of  proposed  system  concepts 
and  upgrades  for  the  Navy  Theater  Wide  Mission  Program. 

The  DRM  will  be  constructed  to  represent  the  operational  environment  circa  2010.  This 
timeframe  has  been  selected  since  it  is  several  years  past  the  scheduled  NTW  BLK  II 
deployment  date.  It  is  unreasonable  to  assess  a  full  campaign  involving  NTW  combat  forces  at 
the  time  of  first  deployment  because  sufficient  numbers  of  NTW  equipped  ships,  equipment  and 
logistics  support  would  not  be  available. 

The  DRM  will  define  the  campaign  at  several  levels  as  illustrated  in  Figure  2-7.  The 
individual  engagements  will  be  defined  in  detail  to  enable  evaluation  of  individual  system 
performance.  Multiple  engagements  will  be  combined  into  Operational  Situations  (OPSITS) 
which  will  be  used  to  evaluate  NTW  systems  in  the  broader  context  of  a  Joint  Task  Force.  The 
OPSITs  will  then  be  combined  into  a  full  joint  force  theater  wide  campaign.  The  DRM  is  an 
engineering  tool  that  will  be  used  in  the  evaluation  of  the  NTW  System  to  stress  all  aspects  of  the 
system  from  performance  and  functionality  to  interoperability  and  supportability. 


CONTENTS 


THEATER  FORCES 
Joint/Allied  Operations 
Extended  Time 
Multiple  Phases  &  OPSITS 
Support  Infrastructure 

TASK  FORCE 
Force  Disposition 
Multiwarfare  Roles 
Multiple  Engagements 
CONOP8/T  actics 

SYSTEM 

Threat  Characterization 
Engagement  Geometry 
Operational  Environment 
Joint  TAD  Interaction 
Excursions 


SITUATION  LEVEL 


Figure  2-7.  DRM  Domain 
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Figure  2-8  shows  that  the  DRM  will  be  more  than  a  single  event  with  specific  threats. 
The  DRM  will  define  the  total  envelope  of  the  operational  environments  in  which  the  NTW 
System  must  perform  from  the  early  stages  of  initial  presence  to  the  end  of  hostilities.  For  NTW 
it  is  important  to  evaluate  the  contribution  of  the  Navy  TBMD  System  when  the  Navy  is  first  in 
theater  and  also  after  other  TBMD  systems  are  in  place. 


Figure  2-8.  DRM  Total  Envelope 


The  DRM  will  consist  of  politically  and  geographically  generic  OPSITs  with  specific 
representative  threats.  The  DRM  will  specify  the  entire  operational  environment  not  just  the 
threats,  raid  sizes  and  timing.  This  will  include  the  physical  phenomena  such  as  clutter  and 
propagation  effects  as  well  as  EW  and  system  availability.  The  DRM  will  contain  the  necessary 
features  and  details  to  evaluate  each  of  the  requirements  from  the  Operational  Requirements 
Traceability  Matrix. 

In  addition  to  the  development  of  the  DRM,  Step  1  will  answer  the  following 
fundamental  questions  to  focus  the  subsequent  steps  and  establish  a  clearer  understanding  of  the 
operational  environment  that  needs  to  be  modeled: 

•  What  specific  OPSITs  will  be  evaluated? 

•  For  what  combination  of  OPSITs  will  the  NTW  design  be  optimized? 

•  What  is  the  temporal  and  spatial  disposition  of  theater  assets? 

•  What  Concept  of  Operations  (CONOPs)  and  Rules  of  Engagement  (ROEs)  will  be 
assumed  for  each  OPSIT? 

•  What  are  the  design  driving  characteristics  of  the  threats  and  situations  that  stress  the 
NTW  System  and  enable  the  evaluation  of: 
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-  Ability  to  engage  the  threat; 

-  Extent  of  the  protected  battlespace; 

-  Availability  of  the  system; 

-  Training  required  to  fight  effectively; 

-  Risk  of  incorrect  engagement  decision;  and 

-  Impact  of  force  structure  and  operational  concept. 

Figure  2-9  shows  the  input  to  Step  1  and  the  process  that  will  be  executed  to  develop  the 
outputs. 

JHU/APL  will  lead  the  development  of  the  DRM  with  major  involvement  by  NSWCDD. 
Two  work  groups  will  be  established  to  support  the  development  of  the  DRM.  The  Engineering 
Work  Group  will  be  comprised  of  TAD  analysts  and  design  experts.  The  Engineering  Work 
Group  will  be  responsible  for  identifying  the  driving  characteristics  to  adequately  evaluate  each 
aspect  of  the  NTW  System.  The  Operational  Work  Group  will  include  warfighters  with 
experience  in  defining  and  executing  the  related  TAD  missions.  The  Operational  Work  Group 
will  provide  guidance  and  review  of  the  CONOPs,  ROEs,  and  operational  situations  to  ensure 
that  the  DRM  is  truly  representative  of  naval  and  joint  force  evolutions.  Both  work  groups  will 
be  led  by  JHU/APL  and  the  participants  are  identified  in  Table  1-1.  JHU/APL  will  be 
responsible  for  the  coordination  and  passing  of  information  from  the  work  groups  for 
incorporation  into  the  DRM. 


2.5.1  Step  1  Inputs 

•  Operational  Requirements  —  An  initial  version  of  the  NTW  operational  requirements 
being  identified  in  Step  0  are  required  to  properly  reflect  the  mission  of  the  system 
and  develop  the  DRM. 

•  Elements  from  previously  developed  scenarios,  DRMs  and  related  program 
evaluations  which  are: 

-  Mission  Profile  -  Threats 

-  Force  'Structure  -  Environment 

•  Functional  Descriptions  -  The  definition  of  the  top-level  functions  will  be  developed 
in  Step  2  in  parallel  with  the  DRM  definition.  An  understanding  of  the  top-level 
functions  is  required  to  ensure  that  the  proper  characteristics  are  included  in  the  DRM 
to  evaluate  all  aspects  of  the  system. 


2-18 


NSWCDD/MP-99/12 


2.5.2  Review  Existing  Scenarios  at  the  Theater  and  System  Level 

Previously  developed  and  approved  OPSITs  and  detailed  engagement  scenarios  will  be 
evaluated  from  past  and  ongoing  TBMD  related  analyses.  The  OPSITs  will  be  evaluated  to 
determine  whether  they  include  characteristics  needed  to  exercise  the  full  NTW  functionality. 
The  OPSITs  will  also  be  reviewed  to  determine  the  level  of  non-TBMD  characteristics  that  are 
included  for  determining  the  impact  of  resource  utilization. 


2.5.3  Review  and  Identify  CONOPs  and  ROEs 

The  recently  developed  Navy  TBMD  CONOPs  will  reviewed  in  the  context  of  the 
scenarios  identified  in  Section  2.4.2.  The  required  changes  and  additions  to  the  CONOPs  will  be 
developed  to  describe  the  command  and  communication  structures  with  sufficient  detail  to 
enable  accurate  modeling  and  analysis  of  the  situations  identified  above.  ROEs  that  have  been 
utilized  in  the  past  during  similar  situations  will  be  obtained  for  each  of  the  general  phases  of  the 
DRM  from  pre  to  post  hostility  and  reviewed  for  possible  variations.  While  the  ROEs  may  not 
significantly  impact  the  TBMD  response,  they  will  impact  the  resource  utilization  and  response 
for  systems  that  also  perform  non-TBMD  functions.  The  Operational  Work  Group  of 
warfighters  and  systems  engineers  with  NTW  experience  will  be  utilized  to  provide  guidance 
and  review  of  the  CONOPs  and  ROEs. 
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2.5.4  Identify  Threat  and  Situation  Drivers 

The  Engineering  Work  Group  of  TBMD  experts,  will  review  the  OPSITs,  CONOPs, 
ROEs  and  threat  documentation  to  determine  the  characteristics  which  most  significantly  impact 
the  overall  performance  of  the  NTW  System.  Once  the  Engineering  Work  Group  has  determined 
a  preliminary  set  of  system  drivers,  a  correlation  with  the  composite  functional  description  of  the 
system  being  developed  in  Step  2  will  be  performed.  The  purpose  of  the  correlation  is  to 
determine  if  each  of  the  top-level  functions  will  be  evaluated  with  the  selected  set  of  drivers. 
These  performance  drivers  will  be  organized  into  logical  groupings  and  quantifiable  limits  or 
boundaries  will  be  documented. 


2.5.5  Define  Design  Reference  Mission 

spectrum  of  operational  situations  to  enable  accurate  modeling  without  providing 
additional  information  that  has  little  or  no  impact  on  the  real  world  system  performance. 
Incorporating  factors  that  impact  real  world  performance  (factors  that  traditionally  have  not  been 
incorporated  in  the  analysis  of  individual  systems)  is  the  challenge  in  developing  the  DRM. 
Impacting  factors  to  be  considered  include  dynamic  adversary  response,  reactive  threats  and 
timeliness  of  intelligence. 

A  single  document  will  be  developed  which  details  the  mission  timeline,  threat 
characteristics  and  OPSITs  to  adequately  evaluate  the  NTW  System  in  the  context  of  a  joint 
force  campaign.  The  DRM  will  be  put  under  interim  configuration  management  after  the 
internal  review  and  full  configuration  management  and  control  will  be  put  in  place  following  the 
ORR. 


A  DRM  analysis  report  will  be  written  which  includes  the  details  of  the  analysis 
performed  and  rationale  used  to  develop  the  DRM.  This  report  will  also  include  sufficient 
traceability  from  approved  originating  documents  to  the  various  DRM  components. 

2.5.5. 1  Threat  Selection  and  Definition 

A  key  characteristic  of  the  DRM  is  the  threat  representation.  For  the  NTW  evaluation  the 
primary  threats  are  theater  ballistic  missiles  which  have  been  defined  in  the  Capstone  STAR  with 
a  NTW  appendix  currently  being  drafted  for  the  FY98  DAB  .  The  TBMD  definitions  have  been 
extensively  studied  by  the  TBMD  COEA  and  are  currently  being  coordinated  by  a  Threat 
Steering  Group  being  led  by  PEO(TAD)-SE/CM. 

In  addition  to  the  TBM  threats,  the  DRM  must  include  some  basic  definition  of  other 
threats,  aircraft  and  anti-ship  missiles,  that  impact  resource  utilization.  However,  unlike  the 
TBM  threats,  these  other  threats  will  not  be  extensively  defined  since  system  performance  is 
against  these  threats  is  not  being  evaluated  by  this  study. 

The  evaluation  and  selection  process  for  all  of  the  threat  types  must  consider  the 
likelihood  of  encountering  the  threat  and  the  unique  characteristics  of  the  threat  which  stress  the 
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performance  or  functionality  of  the  NTW  System.  Performance  and  functionality  excursions, 
such  as  countermeasures  or  enhanced  capability,  will  be  defined  as  needed  to  thoroughly 
evaluate  NTW  performance. 

As  the  threats  are  selected  for  inclusion  in  the  DRM,  the  available  threat  documentation 
must  be  reviewed  by  the  engineering  IPT  to  determine  if  the  proper  level  of  characterization  is 
available.  The  level  of  characterization  may  vary  significantly  depending  on  the  threat  type  and 
analysis  tool  that  will  be  used.  For  example,  the  general  sensitivity  analysis  performed  in  Step  3 
with  the  force-on-force  model  will  require  far  less  detail  than  the  engineering  models  that  may  be 
used  for  specific  system  level  evaluations.  The  detailed  characterization  required  includes  but  is 
not  limited  to:  trajectory,  radar  and  EO  signature,  countermeasures,  vulnerability  to  hard-kill  and 
soft-kill.  For  those  threats  about  which  limited  detail  is  available,  the  missing  characteristics  will 
be  developed  as  required. 

2.5.5.2  Mission  and  OPS  IT  Description 

A  sequence  of  OPSITs  will  be  defined  at  the  various  phases  of  the  campaign  that  stress 
the  various  aspects  of  NTW  in  the  context  of  joint  TBMD.  The  OPSITs  will  include  non-TBMD 
threats  and  features  at  a  lower,  but  sufficient,  detail  to  enable  an  assessment  of  the  utilization  of 
systems  that  support  other  mission  programs.  The  DRM  will  also  include  details  on  the  overall 
campaign,  such  as  force  structure,  ship  deployment  cycle,  and  support  system  assumptions,  to 
enable  evaluation  of  availability  and  maintainability. 

The  operational  requirements  and  driver  characteristics  will  serve  as  a  cross-check  to 
ensure  that  the  OPSITs  encompass  the  bounds  of  NTW. 

To  provide  a  complete  description,  the  DRM  will  contain  information  concerning  all 
aspects  of  the  campaign: 

•  Geopolitical  Situation 

•  Overview  of  Adversary 

•  Overview  of  Joint  Force 

•  Campaign  Phases  and  Timeline 

•  Detailed  OPSITs 

Each  detailed  OPSIT  will  provide  the  information  required  for  modeling  and  simulation 
of  the  NTW  System  performance: 
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•  Adversary  Definition 

-  Force  Disposition 

-  Raid  Composition 

•  Joint  Force  Definition 

-  Force  Disposition 

-  CONOPs  and  ROEs 

•  Neutral  Definition 

-  Background  Air  Traffic 

-  Background  Surface  Traffic 

•  RF  Environment 

-  Background  Emitter  Environment 

-  Electro-Magnetic  Enironment 

•  Natural  Environment 

-  Topography 

-  Weather 

Variations  or  excursions  will  be  defined  in  the  DRM  to  enable  the  evaluation  of  system 
performance  in  2010  and  will  reflect  changes  in  threat  characteristics,  population  and  the 
introduction  of  new  or  improved  own  force  assets. 


-  Propagation  Effects 

-  Clutter 


-  Threat  Characteristics 

-  Counter  Measures 


2.5.6  Preliminary  NTW  SRD  Threat/Environment  Section 

At  the  completion  of  Step  1,  a  summary  of  the  NTW  threat  and  operational  environment 
developed  for  the  DRM  will  be  documented  for  incorporation  into  the  NTW  SRD. 


2.5.7  Operational  Requirements  Review 

A  review  of  the  draft  DRM  will  be  conducted  with  the  members  of  both  work  groups  and 
NTW  management  to  obtain  final  comments  and  agreement  on  the  content.  The  formal  review 
and  approval  of  the  DRM  will  be  performed  at  the  Operational  Requirements  Review  (ORR). 


2.5.8  Step  1  Products 

•  Design  Reference  Mission; 

•  Preliminary  NTW  SRD  Threat/Environment  Section;  and  a 

•  DRM  Analysis  Report 
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2.6  STEP  2  -  DEFINE  SYSTEM  BOUNDARIES 

The  intent  of  this  step  in  the  system  requirements  engineering  process  is  to  describe  the 
functions  to  be  performed  by  NTW  TBMD  and  the  boundaries  and  interrelationships  of  NTW 
and  its  subsystems  with  other  Joint  Theater  Warfare  systems  and  subsystems.  This  step  will 
document  NTW  interfaces  and  information  flow  and  identify  areas  where  functional 
relationships  cross  system  boundaries  and  may  result  in  potential  performance  sensitivities.  See 
Figure  2-10.  The  NTW  System  is  in  the  center  box  with  external  interfaces  depicted  around  it. 


Figure  2-10.  NTW  System  Boundaries 


At  this  stage  of  the  engineering  process  the  intent  is  not  to  constrain  the  allocation  of 
specific  new  NTW  derived  functionality  but:  (1)  to  understand  and  document  the  functionality 
required  to  conduct  NTW,  (2)  to  understand  the  physical  and  functional  relationships  between 
current  subsystems  that  will  be  included  in  NTW  and  (3)  to  understand  and  document  the 
interfaces  and  functional  interrelationships  between  NTW  and  other  Joint  and  Navy  Air  Defense 
related  systems,  as  well  as  national  assets.  An  overall  product  of  this  step  will  be  a  descriptive 
hierarchical  “functional  description”  of  NTW  embedded  in  a  system  engineering  tool  database. 
The  database  will  include  functional  descriptions,  intra  and  intersystem  interfaces,  boundaries 
and  functional  flow  diagrams.  Functions  performed  by  interfacing  systems  will  also  be  included 
when  they  impact  on  the  conduct  of  NTW.  The  database  will  also  include  key  NTW  related 
performance  characteristics  of  those  current  subsystems  that  will  be  included  in  NTW.  The 
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functional  description  developed  in  this  step  will  address  the  full  set  of  operational  requirements 
coming  out  of  Step  0  and  will  provide  the  basis  for  identifying  functions  not  currently  being 
performed  by  existing  systems.  This  step  provides  an  input  to  the  development  of  system 
alternatives  to  be  performed  in  Step  4. 

Figure  2-1 1  provides  an  overview  of  the  system  requirements  engineering  processes  to  be 
carried  out  in  Step  2.  This  step  is  intended  to  answer  the  following  questions: 

•  What  are  the  boundaries  of  the  “NTW  System”? 

•  What  are  the  current  subsystems  that  will  be  part  of  NTW  and  what  NTW  related 
functions  do  they  currently  perform?  What  are  their  key  performance  characteristics 
that  relate  to  the  conduct  of  NTW? 

•  What  are  the  NTW  internal  and  external  interface  requirements  and  characteristics? 

•  What  are  the  interoperability  requirements? 

•  What  are  the  NTW  related  functions  that  must  be  performed? 

•  What  are  the  relationships  and  interfaces  between  those  functions? 

This  step  will  build  on  Area  and  NTW  efforts  and  studies  that  are  underway  or  have  been 
conducted  to  date.  This  step  will  be  led  by  JHU/APL  with  support  from  NSWCDD,  NTW 
element  system  engineers  and  other  participants  as  defined  in  Table  1-1. 
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2.6.1  Step  2  Inputs 

As  depicted  in  Figure  2-11,  the  major  inputs  to  this  step  are  as  follows: 

•  Operational  Requirements  Report  from  Step  0; 

•  Operational  Requirements  Traceability  Matrix  from  Step  0; 

•  Area  TBMD  System  Requirements  Document; 

•  Existing  subsystem  documentation;  and 

•  DRM  from  Step  1 . 

2.6.2  Systems  to  be  Addressed 

This  step  will  address  all  nomenclatured  systems  that  play  either  a  direct  or  significant 
indirect  role  in  Navy  Theater  Wide  TBMD.  The  Navy  Theater  Wide  TBMD  capability  will  be 
built  on  that  developed  for  Area  TBMD.  In  addition,  many  of  the  nomenclatured  systems  that 
are  elements  of  NTW  support  other  non-NTW  Air  Defense  functions.  These  non-NTW  Air 
Defense  functions  contribute  to  the  environment  in  which  NTW  is  conducted  and  in  many  cases 
compete  for  resources  when  executing  NTW.  To  the  degree  that  these  functions  impact  NTW 
they  will  be  included  as  part  of  this  system  requirements  engineering  effort.  Likewise  all 
interfacing  systems  that  may  substantially  impact  on  NTW  (e.g.  cueing,  positioning,  C3,  tracking 
etc.)  will  be  addressed.  Core  NTW  elements  are  listed  in  Table  2-1.  Interfacing  subsystems  are 
given  in  Table  2-2. 
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Table  2-1 .  Core  NTW  Elements 

_ AEGIS  Weapon  System  (As  modified  for  Area  and  NTW): _ 

_ AN/SPY- 1  -  modified  for  TBMD _ _ _ 

_ AEGIS  Command  and  Decision  (C&D) _ _ _ 

_ AEGIS  Weapons  Control  System  (WCS)  _ 

_ AEGIS  Fire  Control  System  (FCS) _ _ _ 

_ AEGIS  Display  System  (ADS) _ 

_ AEGIS  Combat  Training  System  (ACTS)  _ 

_ AEGIS  Operational  and  Readiness  Test  System  (ORTS) _ 

_ Vertical  Launch  System  (VLS) _ _ _ 

_ NTW  Interceptor _ _ _ _ _ 

_ High  Power  Discriminating  Radar* _ _ 

_ Concentric  Canister  Launcher  (CCL)*  _ 

SPY-2* _ _ _ 

SEA  ATHENA* _ 

BMC4!: _ 

_ Exterior  Communication  System  (EXCOM) _ 

_ Joint  Tactical  Information  Distribution  System  (JTIDS/Link  16)  -  Joint  Data  Network  (JDN) 

LINK-11 _ _ _ 

TRAP/TRE _ _ _ 

_ Joint  Maritime  Command  Information  System  (JMCIS)  -  Joint  Planning  Network  (JPN) 

_ CEC  -  Joint  Composite  Tracking  Network  (JCTN) _ _ 

_ Shipboard  AADC-  Area  Air  Defense  Commander _ 

_ Tactical  Data  Distribution  System  (TDDS)  -  Replacement  for  Trap/TRE _ 

*  Potential  New  Development  Item 
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Table  2-2.  Interfacing  Systems 


Other  Shipboard  Systems: 

JMCOMS  (Joint  Maritime  Communications) 

SM-2  Block  IVA  -  Area  Defense  Interceptor 

TIMS  -  TFCC  (Tactical  Hag  Command  Center)  Information  Management  System 

BMC4I: 

Global  Command  and  Control  System  (GCCS-M)  -  Shipboard  connectivity  via  JMCIS 

Tactical  Information  Broadcast  System  (TIBS) 

National  Sensor  Support: 

Defense  Support  Program  (DSP) 

Space  Based  Infrared  System  (SBIRS-HEO) 

Space  Missile  Tracking  System  (SMTS/SBIR-LEO) 

Global  Positioning  System  (GPS) 

IN  THEATER  SYSTEMS: 

THAAD 

JSTARS 

Patriot 

Hawk 

TPS-59 

TPS-75 

E-2C 

AWACS 

Airborne  Laser 

2.6.3  Develop  NTW  Theater  Ballistic  Missile  Defense  Functional  Descriptions 

2.6.3. 1  Develop  Functional  Descriptions  of  NTW 

The  objective  of  this  substep  is  to  produce  a  functional  description  of  NTW.  A  database 
that  contains  hierarchical  functional  definitions  of  the  systems  that  are  elements  of  NTW  will  be 
developed.  This  functional  description  will  only  address  functions  that  are  directly  related  to 
NTW  or  impact  NTW  related  resources.  These  functional  descriptions  will  be  drawn  from 
existing  system  documentation,  the  Area  TBMD  SRD  and  a  functional  decomposition  from  the 
operational  requirements  defined  in  Step  0.  This  functional  description  will  form  the  basis  for 
the  establishment  of  performance  requirements  in  Step  3  and  the  allocation  of  functions  and 
performance  to  individual  elements  to  be  done  in  Step  4.  The  functional  decomposition  will  only 
go  to  that  level  required  to  clearly  define  the  key  functional  and  performance  requirements  to  be 
allocated  to  these  elements  and  to  understand  the  role  each  element  plays  in  overall  NTW. 

2.6. 3. 2  Document  Current  Performance  Characteristics  of  NTW  Subsystems 

Since  NTW  will  encompass  modifications  to  elements  of  the  AEGIS  Weapon  System  it 
is  important  to  understand  how  those  elements  perform  in  areas  related  to  NTW.  NTW  related 
performance  characteristics  will  be  abstracted  from  existing  documentation  and  inserted  in  the 
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database.  Emphasis  will  be  on  those  characteristics  that  are  visible  to  other  elements  of  NTW 
and  that  impact  on  overall  NTW  performance.  In  addition  to  these  performance  characteristics, 
key  compatibility  and  interoperability  characteristics  will  also  be  abstracted  and  added  to  the 
database. 


2.6.4  Identify  and  Document  NTW  Interfaces 

This  section  addresses  the  functional  definition  of  the  interfaces  between  NTW 
subsystems  and  between  NTW  and  non-NTW  elements  as  well  as  the  strategy  and  architecture 
used  to  integrate  the  various  NTW  subsystems.  This  section  has  four  main  elements: 

•  The  identification  of  external  interfaces  and  the  addition  of  interfacing  systems  to  the 
functional  database. 

•  The  addition  of  functional  interface  information  to  the  database; 

•  The  identification  of  key  performance  characteristics  for  interfaces  that  are  potential 
“stress”  points  in  terms  of  performance;  and 

•  The  documentation  of  interoperability  requirements. 

2.6.4. 1  Develop  Functional  Descriptions  of  Systems  that  Interface  to  NTW 

External  interfaces  will  be  identified  and  the  functional  database  built  in  the  proceeding 
section  will  be  expanded  to  include  those  Navy  and  non-Navy  systems  that  support  and  interface 
with  the  systems  that  make  up  NTW.  The  emphasis  will  be  placed  on  those  aspects  of  these 
systems  that  contribute  to  TBMD  and  those  which  compete  for  resources  that  are  used  in 
conducting  NTW. 

2.6.4.2  Develop  Interface  Descriptions  and  Functional  Flow  Diagrams 

Functional  interface  descriptions  and  functional  flow  information  will  be  added  to  the 
database  developed  in  Section  2.5.3.  The  database  will  link  the  interface  data  flow  to  originating 
and  receiving  subfunctions  as  well  as  originating  and  receiving  elements.  The  database  will 
include  both  intra-NTW  interfaces  and  interfaces  to  non-NTW  systems  and  will  be  used  for 
interface  and  functional  analysis.  An  analysis  will  be  conducted  to  identify  situations  where  an 
NTW  related  function  is  closely  coupled  to  a  function  in  a  non-core  NTW  element  or  to  a  new 
or  modified  function  in  a  core  NTW  element  and  that  function  is  sensitive  to  changes  in  the 
interface  or  implementation  of  the  interfacing  function.  These  areas  will  be  noted  for  subsequent 
analysis  in  Step  4. 

2.6.4.3  Identify  Kev  Interface  Performance  Characteristics 

A  report  will  be  developed  that  identifies  key  NTW  interface  requirements.  Interface 
performance  characteristics  that  stress  or  significantly  impact  performance  such  as  data  link 
reporting  latency  will  be  identified  and  included  in  the  database. 
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2. 6.4.4  Identify  Interoperability  Requirements  for  Integration  of  NTW  with  Other 
Systems 

This  substep  focuses  on  the  requirements  for  integrating  NTW  with  non-core  NTW 
systems.  The  objective  of  this  substep  is  to  develop  an  understanding  of  the  current  integration 
strategies  being  used  and  their  implications  on  interoperability,  life  cycle  cost  and  system 
performance.  Current  interoperability  and  interface  standards  and  protocols  that  govern 
interfaces  between  NTW  and  other  systems  will  be  identified.  When  practical,  existing 
documentation  will  be  summarized  and  referenced  rather  than  generating  new  descriptions. 
Potential  system  bottlenecks  resulting  from  interfacing  architecture  or  techniques  that  may 
impact  overall  NTW  performance  will  be  identified.  NTW  related  databases  that  are  used  by 
more  than  one  system  shall  also  be  identified  and  documented. 


2.6.5  Update  Functional  and  Interface  Description  Based  on  Steps  3  and  4 

It  is  anticipated  that  the  functional  and  interface  description  will  be  modified  after  Steps  3 
and  4  as  functions  are  restated  and  repartitioned  to  better  reflect  the  need  for  the  allocation  of 
performance  to  functions  and  subfunctions,  and  functions  and  subfunctions  to  elements. 


2.6.6  Step  2  Products 

The  following  products  will  be  produced  by  this  step: 

•  NTW  Hierarchical  Functional  Descriptions; 

•  Interface  Descriptions  and  Functional  Row  Diagrams; 

•  Key  NTW  Interface  Performance  Characteristics; 

•  Description  of  Interoperability  Requirements;  and 

•  Initial  Draft  of  the  Scope,  Functional  and  Interface  Requirements  for  the  SRD. 
The  products  of  this  step  and  those  of  Steps  0  and  1  will  be  reviewed  at  the  ORR. 
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2.7  STEP  3  -  IDENTIFY  SYSTEM/SUBSYSTEM  ATTRIBUTES  THAT  SUPPORT 

HIGHER  LEVEL  SYSTEMS 

The  objective  of  this  step  is  to  identify  the  key  NTW  system  and  subsystem  attributes  that 
significantly  contribute  to  the  successful  completion  of  the  TBMD  mission  and  to  translate  these 
findings  into  a  Conceptual  Performance  Baseline  comprised  of  top-level  functional  and 
performance  requirements. 

Step  3  is  designed  to  identify  the  critical  NTW  functions  and  their  key  attributes  that 
contribute  to  warfighting  success  and  to  begin  the  iterative  process  necessary  to  incorporate  risk 
and  affordability  into  the  Conceptual  Performance  Baseline  (CPB).  Figure  2-12  shows  that  a 
balance  of  cost,  schedule,  and  performance  are  important  considerations  in  defining  NTW 
requirements  and  capabilities. 


Given: 

•  Fixed  Schedule 

•  Best  Case/Worst  Case 

-  Hostile  Force  Disposition 

-  Raid  Size  and  Composition 

-  Environment 

-  Countermeasures 

•  Target  Type 

•  Composite  DRM 


Variables 

Dominance  Volume 
Sensitivity 

•  Firm  Track  Range 

•  Cue 

• CONOPS 

•  Sensor  netting  ; 

•  Reaction  Time 

•  Missile  Kinematics 

•  Joint  Interoperability 

Variables 

Single  Shot 
PK  Sensitivity 

•  Sensor  Discrim. 

•  Seeker  Dfscrim. 

•  Guidance  Accuracy 

•  Divert  Capability 

•  Lethality 

•  Kill  Assessment 

•  Reliability 

■ 

Variables 

^Sensitivity 

•  Ship  System  Aq 

•  Logistics 

•  CONOPS 

-  ShipsAssigned 

-  Load  Out 

-  Battle  Mgmt 
•Training 

•  A0of  Netted 

Sensors 

•  Human  Factors 

Schedule 


Figure  2-12.  NTW  Candidate  Key  Attributes 

The  Conceptual  Performance  Baseline  developed  in  this  step  will  be  used  in  Step  4  to 
establish  the  NTW  Functional  and  Allocated  Baselines,  including  the  functional  and  performance 
requirements  for  NTW  subsystems  (nomenclatured  systems).  Figure  2-13  shows  the  process 
required  to  develop  the  CPB. 
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Key  questions  this  step  is  designed  to  answer  include: 

•  What  are  the  key  attributes  and  associated  performance  measures  of  the  NTW  critical 
functions? 

•  How  do  potential  affordability  constraints  affect  NTW  mission  success? 

•  What  are  the  top-level  NTW  system  functional  and  performance  requirements,  which 
are  critical  to  ensure  that  the  Mission  Success  Criteria  (MSC)  is  met? 


2.7.1  Step  3  Inputs 

As  shown  in  Figure  2-13,  Step  3  requires  several  key  inputs  from  previous  steps.  These 
inputs  include: 

•  Operational  Requirements  Traceability  Matrix  -  The  Operational  Requirements 
Traceability  Matrix,  generated  in  Step  0,  will  provide  the  starting  point  to  begin  the 
requirements  iteration  process; 

•  Operational  Requirements  Report  -  The  Operational  Requirements  Report  generated 
in  Step  0  documents  requirements  issues  and  their  resolution; 

•  Design  Reference  Mission  -  The  Design  Reference  Mission  developed  in  Step  1 
provides  the  design  stressing  composite  scenarios  to  be  used  in  analyses  identifying 
critical  functions  and  key  attributes; 

•  NTW  Functional  Description  -  The  Functional  Description  of  NTW  developed  in 
Step  2  will  provide  the  basis  from  which  critical  functions  and  their  attributes  will  be 
identified; 

•  Previous  and  ongoing  TBMD  studies;  and 

•  Navy  TBMD  COEA  Phase  II. 


2.7.2  Identify  System  Attributes  and  Success  Criteria 

A  set  of  NTW  system  attributes  which  are  critical  to  the  Joint  TBMD  mission  success 
will  be  identified  by  collecting,  organizing,  and  agreeing  upon  data  derived  from  Steps  0  through 
2  of  this  plan.  It  is  essential  that  data  be  included  from  previous  and  ongoing  NTW  studies  as 
well  as  the  Navy  TBMD  COEA  Phase  II.  In  order  to  determine  which  attributes  represent  the 
key  system  attributes,  success  criteria  must  be  developed  to  determine  the  impact  an  attribute  has 
on  the  NTW  System’s  contribution  to  the  Joint  TBMD  mission.  These  attributes  will  then  be 
assessed  to  determine  their  contribution  to  system  performance  through  a  modeling  and 
simulation  process.  An  NTW  System  Attributes  and  Success  Criteria  Report  will  be  generated  to 
document  the  results. 

2.7.2. 1  Identify  Mission  Success  Criteria 

MSCs  are  defined  as  standard  outcomes  for  which  a  defense  success  can  be  credited. 
NTW  mission  success  is  defined  by  how  well  a  set  of  assets  are  defended. 
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2.1 2.2  Identify  System  Attributes 

System  attributes  are  defined  as  NTW  system  characteristics  which  can  be  organized  into 
various  categories  such  as  functions,  constraints,  performance  parameters,  cost,  physical 
characteristics,  supportability  and  availability. 

A  structured  process  will  be  used  to  take  previously  developed  top-level  requirements 
and  functional  descriptions  developed  in  Steps  0  and  2  and  identify  the  most  critical  functions 
and  system  attributes.  These  critical  functions  and  system  attributes  will  then  be  used  as  inputs 
for  the  modeling  identification  and  analyses  in  Sections  2.6.3  and  2.6.4.  Examples  of  NTW 
system  attributes  are: 

•  Vbo  (Bum  Out  Velocity); 

•  Discrimination; 

•  Detection/Track  range; 

•  Minimum  intercept  altitude; 

•  Cueing  accuracy  and  latency; 

•  Kill  assessment; 

•  Attributes  to  support  interoperability; 

•  Lethality;  and 

•  System  response  time. 

2.7. 2.3  Identify  Measure  of  Effectiveness 

Measure  of  Effectiveness  (MOE)  is  defined  as  characterization  of  battle  outcomes  related 
to  MSCs.  MOEs  define  parameters  which  can  be  used  to  measure  the  effectiveness  of  various 
system  attributes.  An  initial  list  of  MOEs  will  be  determined  by  guidance  from  previous  and 
ongoing  NTW  studies  and  by  the  Navy  TBMD  COEA  Phase  II.  MOEs  are  used  to  quantify  the 
results  of  analysis  performed  in  Section  2.6.4.  Examples  of  NTW  MOEs  include: 

•  Probability  of  Negation  (Pn); 

•  Battle  space; 

•  Forward  defended  range; 

•  Rear  defended  range; 

•  Cross  range; 

•  Raid  rate  capacity; 

•  Engagement  altitude; 

•  Minimum  closing  velocity;  and 

•  Depth  of  fire. 
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2.7.3  Develop  Modeling  Strategy 

System  attributes  defined  in  Section  2.6.2  will  be  assessed  through  the  use  of  a  modeling 
strategy.  A  modeling  strategy  must  be  developed  for  both  performance  and  cost  models 
including  identification  of  the  most  appropriate  models  or  level  of  models.  Assessments  will  be 
made  at  the  appropriate  time  to  determine  which  existing  models  would  meet  the  minimum 
requirements  for  the  respective  aspect  of  the  analysis.  A  spectrum  of  models  will  be  needed  to 
address  the  entire  system  as  well  as  critical  functions  and  attributes,  i.e.,  different  levels  of  detail. 
However  for  this  step,  one-on-one  and  force-on-force  level  models  with  medium  fidelity  are  of 
prime  interest  with  others  used  only  as  required.  Step  4  will  require  extensive  use  of  engineering 
level  models,  as  well  as  force-on-force,  and  these  will  be  addressed  in  that  section  of  this  plan. 
Models  currently  being  used  and  accepted  in  the  NTW  and  Joint  community  will  be  the  primary 
candidates  for  this  step. 

2.7.3. 1  Model  Availability  /  Suitability 

Many  detailed  models  of  the  nomenclatured  NTW  subsystems  exist  and  a  selected  subset 
of  these  will  be  used  in  Step  4.  However,  there  are  very  few  models  capable  of  sensitivity 
analyses  at  the  NTW  level  in  the  full  joint  theater  warfare  context.  The  Extended  Air  Defense 
Test  Bed  (EADTB)  and  the  Extended  Air  Defense  Simulation  (EADSIM)  are  the  preeminent  of 
these.  EADSIM  has  been  widely  used  for  various  force-on-force  applications,  but  lacks  model 
implementation  flexibility  at  the  user  level.  EADTB  which  is  just  now  becoming  fully 
operational  provides  a  much  better  user  modeling  environment.  Furthermore,  recent  Navy 
efforts  with  EADTB  have  led  to  the  development  of  Area  Wide  and  NTW  models  in  this  joint 
model.  Similar  models  in  EADTB  exist  (or  soon  will  exist)  for  Army,  Air  Force  and  Marine 
systems.  Also  Joint  BMC4I  models  are  being  developed  by  the  services,  the  Joint  National  Test 
Facility  (JNTF)  and  the  Ballistic  Missile  Defense  Office  (BMDO).  The  Naval  Air  Engagement 
Model  II  (NAEM  II)  will  be  used  in  the  study  of  interfaces  to  non-NTW  systems  where  it 
provides  unique  capability.  It  is  recommended  that  EADTB  be  used  as  the  principal  joint 
systems  analysis  tool  for  NTW  with  EADSIM  II  being  used  in  a  support/back  up  role. 

2.13.2  Modeling  and  Simulation  Data  Requirements 

There  may  be  unique  data  required  for  the  sensitivity  analyses  in  Section  2.6.4.  For 
EADTB,  much  of  this  is  within  the  domain  of  the  Specific  System  Representation  (SSR)  to  be 
developed  during  the  execution  of  this  plan  by  specific  NTW  subject  matter  experts  and  will  not 
require  modifications  to  the  force-on-force  model.  Exact  data  requirements  have  not  been 
developed  in  this  plan.  However,  work  will  be  initiated  at  project  start  to  further  populate 
EADTB  with  the  required  subsystem  level  of  SSRs  for  NTW. 
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2.7.4  Determine  Key  System  Attributes 

The  step  of  determining  the  key  system  attributes  will  be  based  on: 

•  The  NTW  system  attributes  and  success  criteria; 

•  The  Design  Reference  Mission;  and 

•  The  NTW  Functional  Description  and  critical  interfaces. 

Using  the  modeling  strategy  in  Section  2.6.3,  key  system  attributes  and  critical  functions 
will  be  determined  through  analyses.  The  results  of  these  analyses  will  be  compiled  into  a 
Sensitivity  Analysis  Report  documenting  the  attributes  analyzed,  the  mapping  of  functions,  the 
models  and  databases  used  and  the  results.  This  report  will  form  the  basis  for  developing  the 
NTW  Conceptual  Performance  Baseline.  This  methodology  is  shown  in  Figure  2-14. 
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Figure  2-14.  Methodology  for  Determining  Key  Attributes 
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2.7.4.1  Define  Model  Inputs 

The  NTW  Mission  Success  Criteria,  system  attributes  and  MOEs  developed  in  Section 

2.6.2  will  be  used  to  develop  a  Sensitivity  Analysis  Matrix.  This  matrix  will  provide  the  inputs 
needed  for  the  models  in  order  to  assess  the  sensitivity  of  system  attributes  with  respect  to  high 
level  functions.  The  Sensitivity  Analysis  Matrix  will  be  documented  as  part  of  the  Sensitivity 
Analysis  Report. 

2.7.4.2  Map  NTW  Functional  Descriptions  to  Models 

The  NTW  Functional  Description  prepared  in  Step  2  will  be  mapped  to  the  system 
representation  used  in  the  analysis  models.  The  objective  of  this  mapping  process  is  to  clearly 
understand  how  each  of  the  NTW  functions  is  represented  within  the  model.  Many  of  these 
functions  will  be  explicitly  represented.  However,  many  may  be  hidden  in  assumptions  or 
represented  implicitly  within  the  model.  Results  of  this  exercise  will  be  documented  as  part  of 
the  Sensitivity  Analysis  Report. 

2.7.4.3  Perform  Sensitivity  Analysis 

Selected  models  will  provide  sensitivity  analyses  based  on  the  DRM  and  will  be  run  in 
accordance  with  the  Sensitivity  Analysis  Matrix  and  Functional  Description  mapping  discussed 
above.  Sufficient  numbers  of  runs  will  be  conducted  to  ensure  result  validity.  Values  will  then 
be  determined  for  the  MOEs.  These  values  will  be  scrutinized  to  determine  and  filter  out  the  key 
system  attributes  including  critical  functions.  For  the  most  promising  parameter  sets  evaluated,  a 
corresponding  rough  order  of  magnitude  life  cycle  cost  estimate  will  be  developed  so  that  some 
measure  of  cost  versus  performance  can  be  assessed.  The  process  will  be  reiterated  with 
adjustments  made  to  the  parameter  set  in  order  to  obtain  cost/performance  sensitivities.  The 
final  result  will  be  a  process  derived  set  of  NTW  functional  and  performance  requirements 
within  affordability  constraints  provided  by  the  Operational  Requirements  Report  generated  in 
Step  0.  More  refined  cost  analyses  will  be  completed  in  Step  4  and  the  iteration  loop  exercised 
again  once  the  functional  allocations  have  been  made.  Results  of  all  analyses  will  be 
documented  as  part  of  the  Sensitivity  Analysis  Report. 

A  wealth  of  data  exists  for  NTW  based  on  an  exhaustive  amount  of  analysis  and  trade 
studies  which  have  been  performed  over  the  last  7  years.  Interceptor  kinematics,  ship-based 
sensor  detection  range,  space-based  cueing  time  delays  and  accuracies,  and  discrimination  have 
been  examined  and  resultant  operational/defended  footprints  developed  over  a  wide  variation  of 
parameters.  This  analysis  will  make  maximum  utilization  of  all  previous  sensitivity  studies,  as 
well  as  the  results  from  the  Navy  TBMD  COEA  Phase  II.  This  effort  will  collect  and  collate 
these  past  efforts  and  build/extend  only  where  needed  to  expand  in  the  context  of  Joint  TBMD 
mission  area  or  for  significantly  new  OPSITS  or  environments  derived  from  the  DRM. 
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2.7.5  NTW  Conceptual  Performance  Baseline 

Once  the  sensitivity  analyses  have  been  completed,  several  steps  will  still  be  required 
prior  to  finalizing  the  system  level  CPB.  The  derived  functional  and  performance  requirements 
must  be  reconciled  with  previously  stated  requirements  determined  from  earlier  steps  in  this 
plan.  CPB  options  must  be  developed  offering  alternatives  based  on  technical  and  warfighting 
risks.  Finally,  a  Conceptual  Performance  Baseline  Review  (CPBR)  will  be  held  to  review  the 
CPB  options  and  finalize  the  CPB. 

2.7.5. 1  Requirements  Reconciliation 

Requirements  reconciliation  will  require  an  iterative  process  of  comparing  the  derived 
functional  and  performance  requirements  with  stated  requirements  defined  in  Step  0  and  with  the 
Functional  Description  developed  in  Step  2.  In  addition,  significant  variances  between  the 
required  performance  levels  and  the  affordability  constrained  performance  levels  must  be 
reconciled  where  they  exist.  Once  these  variances  are  reconciled,  CPB  options  can  be  developed 
based  on  the  remaining  primary  issues  of  risk  and  affordability. 

2.7. 5. 2  CPB  Options 

Once  the  derived  functional  and  performance  requirements  are  reconciled,  CPB  options 
will  be  identified  and  will  include  verification  methodology.  A  risk  assessment  will  be 
performed  specifying  when  certain  warfighting  capabilities  are  required  along  with  the  cost 
necessary  to  support  those  capabilities.  Technical  and  warfighting  risks  will  then  be  determined 
due  to  the  impact  of  not  having  certain  warfighting  capabilities  developed  at  certain  times. 
Detailed  risk  management  plans  will  not  be  developed  at  this  time.  The  objective  of  the  risk 
assessment  is  to  determine  if  unacceptable  warfighting  risks  are  incurred  with  cost  driven 
solutions  or  if  alternative  tactics  might  be  employed  to  mitigate  these  risks.  CPB  options  will  be 
based  on  the  risk  assessment  and  will  be  ranked  indicative  of  the  likelihood  of  mission  success 
by  a  consensus  among  Step  3  Work  Group  members. 

2.7. 5. 3  Conceptual  Performance  Baseline  Review  and  Documentation 

CPB  options  will  be  reviewed  with  the  Systems  Engineering  IPT  to  assist  in  finalizing 
recommendations  for  the  CPB.  A  formal  review  of  the  recommendation,  supporting  data  and 
rationale  will  then  be  conducted.  The  Conceptual  Performance  Baseline  Review  team  will  be  led 
by  PMS  452  and  include  selected  personnel  shown  in  Table  1-1.  The  CPBR  will  be  coordinated 
by  JHU/APL  and  NSWCDD. 

The  final  CPB  documentation  will  be  modified,  if  necessary,  based  on  the  results  of  the 
CPBR.  The  CPB  will  include  key  system  attributes  associated  with  each  critical  functional, 
performance  level  required  for  each  attribute,  and  acceptable  cost  goals.  It  will  define  the  agreed 
upon  functional,  performance,  cost  and  warfighting  capability  requirements  for  NTW.  The  CPB 
will  be  placed  initially  under  interim  configuration  control  upon  approval  by  the  Systems 
Engineering  IPT  and  full  configuration  control  after  CPBR  approval.  Once  the  CPB  is  placed 
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under  full  configuration  control,  the  Operational  Requirements  Traceability  Matrix  and 
Functional  Description  will  be  updated. 

The  CPB  will  form  the  basis  for  preliminary  NTW  SRD  sections  reflecting  functional, 
performance  and  verification  requirements.  Also,  the  NTW  Mission  Program  operational 
requirements  updated  by  this  step  will  be  documented  in  preliminary  sections  of  the  SRD. 


2.7.6  Step  3  Products 

The  following  products  will  be  produced  by  this  step: 

•  NTW  Conceptual  Performance  Baseline; 

•  Preliminary  versions  of  the  operational  requirements,  functional  requirements, 
technical  performance  and  verification  requirements  for  the  NTW  SRD; 

•  NTW  System  Attribute  and  Success  Criteria  Report; 

-  Mission  Success  Criteria; 

-  System  Attributes; 

-  Measure  Of  Effectiveness; 

•  Sensitivity  Analysis  Report; 

-  Sensitivity  Analysis  Matrix; 

-  Key  System  Attributes;  and 

•  Conceptual  Performance  Baseline  Review  documentation  which  will  include  the 
CPBR  briefing  package,  action  items  and  results. 
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2.8  STEP  4  -  ESTABLISH  THE  FUNCTIONAL  AND  ALLOCATED  NTW  BASELINES 

The  purpose  of  this  step  in  the  process  is  to  establish  the  FY2010  NTW  Functional 
Baseline  (performance,  functional,  physical)  and  allocate  the  baseline  to  existing  and  proposed 
subsystems.  The  migration  plan  to  achieve  the  Allocated  Baseline  will  also  be  defined  in  this 
step.  See  Figure  2-15. 


•  CPB 

•  NTW  Functional  Description 

•  Area  TBMD  SRD 

•  Previous  NTW  Studies 

•  System  Attribute  and  Success  Criteria  Report 

•  Sensitivity  Analysis  Report 


Establish  NTW  | 

Establish  Allocated 

Functional 

Baseline  (Allocated  to  NTW 

Baseline 

Nomenclatured  Systems)  * 

Ship  Plans/ 
Schedule  < 
NTW  Schedule 


Migration 

Path 


2010  NTW 
Functional/ 
Allocated 
Baselines  (SRD) 


*  The  Allocated  Baseline  in  this  case  is  documented  in  the  SRD  which  the  respective  Program  Offices  will  use  to  develop  their  combat  system  products. 


Figure  2-15.  Establish  the  Baseline 


Figure  2-16  provides  an  overview  of  the  system  requirements  engineering  processes  to  be 
carried  out  in  this  step  in  a  functional  flow  format.  This  step  will  identify  the  functions,  key 
technical  parameters  and  other  attributes  to  be  allocated  to  each  of  the  core  elements 
(nomenclatured  subsystem)  of  NTW.  This  step  also  defines  the  interfaces  and  interoperability 
requirements  between  NTW  and  systems  external  to  NTW. 

This  step  will  answer  the  following  key  questions: 

•  What  are  the  system/subsystem  alternatives  for  FY20 1 0? 

•  What  is  the  strategy  for  integrating  any  new  elements  included  in  these  alternatives? 
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•  What  is  the  cost,  risk,  effectiveness  and  performance  of  the  alternatives  under 
consideration?  Do  they  meet  the  Conceptual  Performance  Baseline,  Top-level  MOE 
and  MSC  defined  in  Step  3? 

•  Which  of  the  alternatives  provides  the  best  balance  between  cost,  risk,  and 
effectiveness  at  the  total  system  level? 

•  What  is  the  migration  path? 

•  What  is  the  recommended  allocation  of  functions,  performance,  effectiveness,  cost, 
and  other  attributes  to  the  NTW  elements? 

This  step  work  group  will  be  co-led  by  NSWCDD  and  JHU/APL  with  support  from 
NTW  element  system  engineers  and  others  shown  in  Table  1-1. 


2.8.1  Step  4  Inputs 

As  depicted  in  Figure  2-16,  the  major  inputs  to  Step  4  are  as  follows: 

•  The  Conceptual  Performance  Baseline  -  developed  in  Step  3; 

•  DRM  -  from  Step  1 ; 

•  Sensitivity  Analysis  Report  -  developed  in  Step  3; 

•  Functional  Descriptions  and  Functional  Flow  Diagrams  -  initially  developed  in  Step  2 
and  updated  after  Step  3; 

•  Area  TBMD  System  Requirements  Document; 

•  Previous  NTW  Studies; 

•  Mission  Success  Criteria  -  from  Step  3; 

•  MOEs  from  Step  3; 

•  COEA  Scenarios/Results;  and 

•  Existing  Test  Data. 


2.8.2  Evaluation  Approach 

The  basic  evaluation  approach  to  be  used  for  this  step  is  to: 

1.  Assess/validate  how  well  alternative  concepts  meet  the  functional  and  performance 
requirements  and  other  attributes  in  the  Conceptual  Performance  Baseline  that  is 
developed  in  Step  3.  This  assessment  will  be  done  using  individual  simulations,  test 
data  for  existing  subsystems  or  other  engineering  analysis  techniques  as  required. 
This  effort  will  make  maximum  use  of  Navy  TBMD  COEA  Phase  II  efforts,  ALI 
lessons  learned,  risk  reduction  activities,  and  other  Navy  studies.  Identification  of  the 
engineering  models  will  be  made  from  the  existing  NTW  technical  community  M&S 
tool  set  after  Step  3  has  defined  the  Conceptual  Performance  Baseline.  No  significant 
modifications  to  the  M&S  tools  currently  available  are  anticipated  for  this  system 
requirements  engineering  effort. 
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Figure  2-16.  Baseline  Establishment  Process 
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2.  Assess  the  performance  and  overall  system  effectiveness  of  alternative  NTW 
concepts  against  the  Mission  Success  Criteria  and  each  of  the  top-level  MOEs  in 
Step  3. 

3.  Assess  cost  including  life  cycle  cost  for  each  of  the  alternatives  being  considered. 

4.  Perform  effectiveness  versus  cost  comparisons  as  part  of  the  process  of  reaching  a 
preferred  system  concept  that  balances  cost,  schedule  and  risk  with  performance.  The 
DRM  developed  in  Step  1  will  provide  the  input  operational  situations  for  these 
evaluations. 

In  refining  the  modeling  and  simulation  strategy  for  this  step  during  the  execution  of  this 
plan,  the  following  questions  will  be  addressed  for  both  performance  and  cost  modeling: 

•  Is  modeling  and  simulation  the  most  effective  method  to  get  answers? 

•  What  exact  questions  do  we  expect  to  answer  using  M&S? 

•  Can  the  answers  be  extrapolated  from  previous  analyses? 

•  What  models  and  simulations  are  best  suited  to  answer  these  questions  within 
cost/schedule  bounds? 

•  What  are  the  limitations  of  the  models  being  used? 

•  Are  there  modifications  required?  What  are  the  modification  costs? 

•  Are  the  answers  a  critical  path  to  the  system  requirements  engineering  process?  What 
is  the  backup  plan  if  the  model  does  not  or  can  not  get  the  answers? 

•  What  are  the  associated  risks  in  using  the  selected  model?  Are  they  acceptable? 


2.8.3  Select  and  Update  Performance  and  Effectiveness  Models 

The  simulations  and  models  from  Step  3  will  form  the  basis  of  the  performance  and 
effectiveness  evaluations  to  be  done  in  this  step.  These  models  will  be  evaluated  to  insure  they 
have  sufficient  fidelity  to  represent  the  functionality  and  performance  characteristics  of  the 
subsystems  to  be  evaluated  in  the  anticipated  NTW  alternatives.  Where  these  models  do  not 
adequately  support  the  effectiveness  evaluations  to  be  performed  in  this  step  other  force-on-force 
models  will  be  evaluated  for  use.  Where  force-on-force  models  are  not  adequate  lower  level 
models  will  be  used.  The  models  that  will  be  considered  for  use  in  this  step  include: 

Force-on-Force  Models 

EADTB 

EADSIM 

NABEM  II 
One-on-One 
KIM 
ADAM 
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High  Fidelity  Engineering  Models 

TRIPOD  SPECTRM 

FIRM  TRACK  PEELS 

SEATRAP  PEGEM 

MEDUSA 
LDS 

DEBRIS  MODEL 


2.8.4  Identify  NTW  System  and  Subsystem  Alternatives 

This  substep  identifies  system  alternatives  to  be  considered  for  the  NTW.  To  bound  the 
scope  of  the  quantitative  performance,  effectiveness  and  cost  analysis  that  will  be  required,  the 
development  and  assessment  of  alternatives  will  be  done  in  two  phases.  The  first  phase  will 
develop  a  set  of  potential  alternatives  with  no  specific  limit  on  how  many  alternatives  should  be 
considered.  This  first  set  will  then  be  assessed  qualitatively  to  narrow  the  number  of  alternatives 
which  will  require  extensive  computer  based  performance  analysis  and  detailed  cost,  risk,  and 
schedule  analysis  in  the  second  phase. 

2.8.4. 1  Propose  NTW  System  Alternatives 

The  alternatives  to  be  considered  will  encompass  the  full  functionality  of  the  NTW 
functional  description  defined  previously  in  Step  2.  The  alternatives  will  be  defined  in  terms  of 
the  functional  and  performance  allocation  to  the  individual  NTW  systems  and  elements.  The 
development  of  alternatives  will  address  full  compliance  with  the  Conceptual  Performance 
Baseline  developed  in  Step  3.  Where  achieving  a  desired  level  of  performance  is  considered  a 
potential  cost  driver,  options  will  be  developed  for  latter  cost  effectiveness  analysis. 

The  alternatives  to  be  developed  will  address: 

•  Functions  not  currently  performed  by  existing  systems  but  required  to  conduct  Navy 
Theater  Wide  TBMD; 

•  Internal  and  external  interface  requirements;  and 

•  Performance  enhancements,  new  developments  and  innovations  required  to  reach  the 
desired  level  of  NTW  performance  and  effectiveness  for  the  FY2010  time  frame. 

The  development  of  alternatives  will  rely  heavily  on  previous  and  ongoing  NTW  studies. 
In  particular  the  ALI,  NTW  Block  I  and  Navy  TBMD  COEA  defined  tactical  configurations  will 
be  considered.  Alternatives  to  be  considered  will  include  a  range  of  sensor  and  missile  options 
including: 

•  Modifications  to  the  current  SPY-1  Radar  Signal  Processor; 

•  The  addition  of  a  high  power  discriminating  radar  to  be  used  in  conjunction  with  the 
SPY-1; 

•  Next  generation  AEGIS  Radar  SPY-2; 
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•  Targeting  by  joint  sensors; 

•  LEAP; 

•  LEAP  with  optimum  booster; 

•  Advanced  Interceptor  Technology  (AIT)  with  new  booster  stack;  and 

•  Advanced  interceptors. 

BMC4I  networks  and  systems  to  be  addressed  include: 

•  Exterior  Communication  System  (EXCOM)(Including  JMCOMS); 

•  Joint  Tactical  Information  Distribution  System  (JTIDS/Link  16)-  Joint  Data  Network 
(JDN); 

•  LINK-11; 

•  TRAP/TRE; 

•  Joint  Maritime  Command  Information  System  (JMCIS)  -  Joint  Planning  Network 
(JPN); 

•  CEC  -  Joint  Composite  Tracking  Network  (JCTN); 

•  Shipboard  AADC-  Area  Air  Defense  Commander;  and  the 

•  Tactical  Data  Distribution  system  (TDDS)  -  Replacement  for  TRAP/TRE. 

In  developing  alternatives,  consideration  will  be  given  to: 

•  Sensitivity  to  changes  in  external  interfaces; 

•  Interoperability  with  other  systems; 

•  Training  and  skills  of  operators; 

•  Ability  of  interface  infrastructure  to  support  throughput  rate  and  timeliness;  and 

•  Schedule,  performance,  and  cost  risks. 

2.8.4.2  Select  Alternatives  for  Detailed  Cost  and  Effectiveness  Analysis 
Each  proposed  alternative  will  be: 

•  Validated  against  the  operational  requirements  identified  in  Step  0; 

•  Validated  against  the  updated  functional  requirements  of  Step  2; 

•  Validated  against  the  performance  baseline  of  Step  3.  Options  that  have  less  than  full 
performance  but  may  result  in  a  cost  effective  solution  will  be  noted  and  earned 
forward  for  detailed  cost  effectiveness  analysis; 

•  Assessed  against  the  top-level  MOEs  including  availability; 

•  Assessed  as  to  ability  to  meet  the  mission  critical  requirements  defined  in  Step  3; 
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•  Assessed  to  determine  system  and  subsystem  sensitivity  to  (1)  changes  in  interfacing 
systems  and  subsystems;  (2)  interface  infrastructure  capacities,  accuracy  and  latencies 
and;  (3)  changes  in  threat; 

•  Assessed  for  inter-system  compatibility  and  interoperability; 

•  Investigated  to  determine  if  current  or  near  term  technology  supports  the  proposed 
subsystem  concepts.  Technology  requirements  will  be  compared  to  currently  planned 
technology  and  functional  road  maps.  Alternatives  in  which  new  technology 
investments  would  result  in  significant  performance,  cost,  or  functional  payoffs  will 
be  identified  and  earned  forward  as  options  for  the  FY20 10  time  frame, 

•  Assessed  as  to  cost  and  schedule  risk; 

•  Assessed  to  determine  if  current  RDT&E  budgets  support  the  alternative;  and 

•  Assessed  for  training  implications. 


The  above  assessments  and  investigations  will  be  engineering  studies  that  will  not  require 
the  use  of  force-on-force  models  and  simulations  that  will  be  used  in  Section  2.7.7. 


The  system  engineering  tool  used  in  Step  2  will  be  used  to  facilitate  the  validation  of  the 
proposed  alternatives  and  insure  functional  completeness  and  traceability  to  requirements.  This 
evaluation  phase  will  not  require  the  use  of  a  force-on-force  simulation  model  but  will  utilize 
engineering  analysis,  individual  subsystem  models  and  qualitative  assessments  to  narrow  the 
scope  of  alternatives  to  be  rigorously  analyzed  in  the  final  selection  process. 

A  set  of  alternatives  will  be  recommended  for  detailed  performance,  effectiveness,  and 
cost  analysis.  This  reduced  set  of  alternatives  should  address  a  range  of  cost  and  performance.  It 
is  recognized  that  this  set  of  alternatives  may  be  similar  to,  and  perhaps  identical  to,  the 
interceptors  currently  under  investigation  by  the  Navy  TBMD  COEA  Phase  II.  However,  this 
analysis  is  necessary  to  complete  the  rigorous  engineering  process  and  tightly  mapped  to  the 
Navy  DRM  and  requirements  flow-down. 


2.8.5  Evaluate  Alternatives  Effectiveness  and  Cost 

2.8.5. 1  Assess  the  Effectiveness  and  Performance  of  the  Proposed  NTW  Alternatives 

The  object  of  this  substep  is  to  quantitatively  assess  the  performance  and  effectiveness  of 
the  alternative  NTW  concepts  selected  for  further  detailed  analysis.  These  alternatives  will  be 
evaluated  against  the  performance  baseline  developed  in  Step  3  and  evaluated  to  determine  how 
effectively  these  alternatives  perform  in  the  context  of  the  FY2010  Design  Reference  Mission 
defined  in  the  previous  steps.  Each  alternative  will  be  assessed  to  determine  it’s  capability  in 
terms  of  the  overall  top-level  NTW  MOEs  defined  in  Step  3. 

The  simulation  models  identified  in  Section  2.7.3  will  be  the  basis  for  the  evaluation  of 
alternative  NTW  effectiveness.  NTW  performance  and  effectiveness  will  be  evaluated  for  each 
of  the  operational  situations  called  out  in  the  DRM.  The  results  from  each  operational  situation 
will  be  weighted  and  combined  to  produce  a  quantitative  determination  of  how  well  the  NTW 
System  concept  meets  the  top-level  MOEs  and  MSC. 
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2.8. 5. 2  Perform  Cost  Analysis  of  Alternatives 

Detailed  total  life  cost  analysis  will  be  performed  for  each  NTW  alternative  under 
consideration.  Cost  analysis  will  be  performed  by  an  EPT  that  includes  the  pertinent  element 
systems  engineers,  logisticians.  Navy  cost  analysts  and  core  NTW  personnel.  Costs  risks  will  be 
identified  and  key  NTW  cost  drivers  will  be  identified  and  used  for  possible  revisions  to  the 
alternatives  under  considered.  Specific  ground  rules  that  shall  apply  to  the  cost  analysis  are  as 
follows: 

•  Costs  to  be  included: 

-  RDT&E  for  ongoing  and  near  term  improvements  and  enhancements 

-  SCN  costs  for  future  installations; 

-  Other  procurement  costs,  i.e.,  OPN,  WPN,  for  planned  future  installations  and 
upgrades; 

-  Projected  20  year  O&S  costs; 

-  Installation  costs  not  in  SCN  and  RDT&E  budgets; 

-  Impact  on  ship  cost; 

•  All  costs  to  be  given  in  FY98  dollars; 

•  Inflation  indices  and  outlay  profiles  will  be  identified  and  agreed  to  at  time  of  plan 
execution; 

•  For  subsystems  that  have  significant  non-NTW  functionality  the  costs  shall  be 
prorated  between  NTW  and  the  other  virtual  high  level  system;  and 

•  Maximum  utilization  of  the  cost  analysis  results  and  methodology  employed  on  the 
Navy  TBMD  COEA  Phase  II  will  be  used. 

This  effort  will  also  identify  the  development,  production,  and  operations  and  support 
cost  drivers  and  issues.  An  assessment  of  the  adequacy  of  current  budget  lines  to  support 
planned  upgrades,  acquisitions  and  support  will  be  made  and  shortfalls  identified.  Areas  for 
possible  cost  savings  will  be  noted. 

2.8. 5.3  Assess  Risks  Associated  with  Each  of  the  Alternatives 

Each  alternative  will  be  assessed  for  technical,  cost  and  schedule  risk.  Specific  risk  areas 
will  be  identified  and  risk  monitoring  and  recommendations  for  risk  management  procedures  for 
use  in  latter  development  phases  will  be  made. 

2.8.5.4  Analyze  Interface  Sensitivity  of  Each  Alternative 

This  substep  will  build  on  the  interface  analysis  done  in  Step  2.  Internal  and  external 
interface  performance  requirements  that  stress  or  significantly  impact  system  performance  such 
as  data  link  reporting  latency  will  be  identified  and  documented.  The  accuracy  and  timeliness 
performance  of  external  system  interfaces  will  be  analyzed  for  impact  on  overall  NTW 
effectiveness  and  performance. 
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2.8.6  Select  Alternatives  that  Balance  Performance,  Cost,  Schedule,  and  Risk 

The  overall  objective  of  the  NTW  system  requirements  engineering  process  is  to  define 
an  FY2010  baseline  that  balances  cost,  effectiveness,  and  risk.  This  baseline  must  be  affordable, 
within  the  scope  of  current  budget  projections  and  must  be  programatically  achievable  within  the 
time  constraints.  The  cost  effectiveness  comparisons  will  be  done  for  a  20  year  life  cycle  .  The 
following  features  of  each  alternative  will  be  ranked  and  compared  against  the  total  NTW  life 
cycle  costs: 

•  Top-level  MOEs; 

•  Performance  against  Mission  Success  Criteria; 

•  Support  of  individual  subsystem  and  higher  level  ORDs; 

•  Support  of  Conceptual  Performance  Baseline  of  Step  3; 

•  Risk; 

-  Overall  development  risk  assessment 

-  Ability  of  subsystems  to  achieve  allocated  performance  requirements 

-  Schedule 

-  Availability  of  required  technology 

•  Time  to  earliest  feasible  IOC  for  the  nomenclatured  systems  comprising  the 
alternative;  and 

•  Sensitivity  to  changes  in  other  subsystems. 

An  IPT  comprised  of  NSWCDD,  JHU/APL  and  effected  program  systems  engineers  will 
be  utilized  in  this  effort. 

2.8.7  Document  Selected  Functional  and  Allocated  Baselines 

The  recommended  alternative  will  be  documented  in  a  Baseline  Report  that  contains  the 
following: 

•  Allocation  of  functions,  performance  requirements,  and  other  attributes  to 
subsystems,  (e.g.,  nomenclatured  subsystems); 

•  NTW  system  functional  architecture  and  tiered  functional  flow  diagrams; 

•  External  and  internal  system  and  subsystem  interface  descriptions; 

•  Traceability  of  performance  and  functional  requirements  to: 

-  The  Conceptual  Performance  Baseline 

-  Top-level  MOEs 

-  Operational  Requirements 

-  Mission  success  criteria 
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•  Integration  strategy; 

•  Required  interface  and  interoperability  standards;  and 

•  Selection  rationale  including  cost,  schedule,  risk  and  performance. 

This  baseline  report  will  form  the  basis  of  the  NTW  System  Requirements  Document. 
The  SRD  will  define  functional,  interface,  performance  and  verification  requirements  at  the 
mission,  at  the  mission  program,  and  at  the  individual  element  levels.  In  addition,  a  Technology 
Development  Requirements  Report,  Risk  Reduction  Prioritization  Report  and  a  non-NTW 
Systems  Interface  Requirements  Report  will  be  written.  The  Technology  Development 
Requirements  Report  will  detail  the  required  technology  efforts  needed  to  support  the  evolution 
to  the  FY2010  capability  along  with  estimates  of  required  funding  and  schedules  for  these 
efforts.  The  Risk  Reduction  Prioritization  Report  will  recommend  risk  reduction  efforts  that 
should  be  performed  in  support  of  the  development  of  the  recommended  NTW  baseline.  The 
non-NTW  systems  interface  requirements  recommendations  will  document  improvements  in 
systems  external  to  NTW  that  are  required  to  support  the  recommended  NTW  alternative  or  that 
provide  cost  effective  enhancements  to  overall  NTW  performance  and  effectiveness. 


2.8.8  Define  Migration  Path 

A  plan  of  actions  required  to  reach  the  NTW  FY2010  baseline  will  be  developed.  That 
plan  will  include  the  following: 

•  Phased  development  plan  that  addresses  the  evolution  of  the  current  AEGIS  Combat 
System  FY2010  baseline; 

•  Top-level  schedules  and  budget  estimates  for  each  required  improvement  and  new 
development; 

•  Assessment  of  current  RDT&E  budgets  to  support  the  evolution  to  the  FY2010 
baseline; 

•  Top-level  ship  integration  plan;  and 

•  POM  inputs  to  implement  migration  path. 


2.8.9  Step  4  Products 

The  following  products  will  be  produced  by  this  step: 

•  Baseline  Report  (Functional  Baseline,  System  Architecture,  and  NTW  Allocated 
Baseline); 

•  Final  NTW  System  Requirements  Document; 

•  Migration  Path  Report; 

•  Non-NTW  Systems  Interface  Requirements  Recommendations  Report; 

•  Analysis  Reports; 
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•  Technology  Developments  Requirements  Report; 

•  Interface  Sensitivity  Analysis  Report;  and  a 

•  Risk  Reduction  Prioritization  Report. 


2.9  STEP  5  -  CONDUCT  MISSION  SYSTEM  REQUIREMENTS  REVIEW  (MSRR)  FOR 

NTW 

The  Navy  Theater  Wide  TBMD  systems  requirements  engineering  process  culminates 
with  the  MSRR  during  which  the  NTW  Allocated  Baselines  (documented  in  the  SRD),  migration 
path,  non-NTW  interface  requirements  recommendations,  technology  development  requirements 
and  supporting  analysis  reports  are  presented  to  the  Navy’s  senior  leadership  for  concurrence, 
transition  to  Program  Managers  (PMs)  for  execution  and  POM  planning  input. 

The  purpose  of  this  step  is  to  obtain  approval  of  the  NTW  Allocated  Baseline 
developmental  requirements  in  the  SRD.  The  MSRR  presents  the  objectives  and  the  allocation 
of  these  requirements  to  both  systems/subsystems  and  external  interfaces.  The  intent  of  this 
review  is  to  obtain  approval  of  the  recommended  NTW  baseline  and  the  proposed  migration 
path.  Recommended  adjustments  to  both  new  and  existing  developments  are  provided  for 
redirection  of  the  present  design  processes  and  POM  planning  input.  The  results  of  this  process 
will  be  updated  and  reviewed  to  incorporate  lessons  learned,  evolving  technology  and  new 
requirements  as  part  of  the  broader  Surface  Navy  Theater  Air  Defense  systems  requirements 
engineering  process. 

The  process  for  conducting  the  MSRR  for  NTW,  follows  the  same  system  requirements 
engineering  model  used  throughout  this  plan  in  which  inputs  are  identified  and  processes  are 
designed  to  achieve  a  desired  output.  Figure  2-17  shows  this  process  and  the  composition  of 
each  of  its  components.  Each  of  these  components  for  executing  the  NTW  is  discussed  in  the 
following  subsections. . 
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2.9.1  MSRR  for  NTW  Objectives 

As  stated  above,  the  MSRR  provides  a  forum  for  presenting  the  results  of  the  NTW 
system  requirements  engineering  process  to  the  Navy’s  senior  uniformed  and  civilian  leadership 
for  concurrence  and  approval  of  the  NTW  baseline,  POM  planning  input  and  approval  for 
transition  to  respective  program  managers  for  execution.  These  objectives  as  well  as  an 
approved  NTW  SRD  and  concurrence  on  non-NTW  requirements  recommendations  are  the 
desired  outputs  of  the  NTW  MSRR. 


2.9.2  Participants 

The  PMS  452  shall  lead  the  NTW  MSRR  with  support  from  JHU/APL  and  NSWCDD 
with  participants  as  identified  in  Table  1-1. 


2.9.3  Step  5  Inputs 

The  Step  5  inputs  are  shown  in  Figure  2-17. 


2.9.4  Material  to  be  Presented 

The  material  to  be  presented  represents  the  products  of  the  NTW  system  requirements 
engineering  process.  The  material  to  be  presented  will  be  the  supporting  NTW  system 
requirements  engineering  products  and  findings  and  will  include: 

•  The  recommended  NTW  baseline  requirements; 

•  Final  NTW  System  Requirements  Document; 

•  Alternatives  considered; 

•  Selection  rationale; 

•  The  migration  path  to  achieve  the  NTW  Allocated  Baseline; 

•  Non-NTW  Systems  Interface  Requirements  Recommendations  Report; 

•  Technology  development  requirements; 

•  Interface  Sensitivity  Analysis  Report; 

•  Key  analysis  results  as  necessary;  and 

•  Risk  Reduction  Prioritization  Report. 


2.9.5  Data  Package 

The  supporting  NTW  system  requirements  engineering  products  and  findings  which 
substantiate  the  recommended  NTW  system  design  will  be  compiled  into  a  data  package  for 
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presentation  and  referenced  at  the  NTW  MSRR.  The  data  package  will  consist  of  the  following 
the  products: 

•  NTW  System  Requirements  Document  (Includes:  top-level  performance 
requirements,  functional  and  performance  allocations  for  each  element  including  the 
key  functional  interface  requirements  and  functional  architecture); 

•  Functional  flow  diagrams; 

•  Functional  descriptions  at  the  NTW  and  element  levels; 

•  Analysis  and  simulation  data; 

•  Draft  recommendations  of  modifications  and  additions  to  the  Naval  TBMD  ORD; 

•  Recommended  interface  standards; 

•  Recommended  interoperability  standards; 

•  Non-NTW  System  Interface  Requirements  Report; 

•  Risk  Reduction  Prioritization  Report;  and  a 

•  Design  Reference  Mission. 


2.9.6  Step  5  Products 

The  outputs  and  products  of  Step  5  are  the  approved  inputs  of  this  system  requirement 
engineering  effort.  The  Naval  TBMD  ORD  recommendations  will  be  passed  to  CNO  N86  for 
consideration.  The  other  output  products  will  be  passed  to  cognizant  program  managers  for 
execution. 
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SECTION  3.0  -  WORK  BREAKDOWN  STRUCTURE 


This  section  provides  the  Work  Breakdown  Structure  (WBS)  and  the  detailed  schedule 
for  executing  the  plan  for  Navy  Theater  Wide  TBM  system  requirements  activities. 


3.1  WORK  BREAKDOWN  STRUCTURE 

The  Work  Breakdown  Structure  for  executing  NTW  system  requirements  engineering  is 
provided  in  Figure  3-1. 
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ACRONYMS  AND  ABBREVIATIONS 


AADC  Area  Air  Defense  Commander 

ACS  AEGIS  Combat  System 

AIT  Advanced  Interceptor  Technology 

ALI  AEGIS  LEAP  Intercept 

ASMD  Anti  Ship  Missile  Defense 

ASN  Assistant  Secretary  of  the  Navy 

ASR  Alternative  Systems  Review 

AWS  AEGIS  Weapon  System 

BMC4I  Battle  Management  Command,  Control,  Communications,  Computers 

and  Intelligence 

BMDO  •  Ballistic  Missile  Defense  Office 


C4I 

CARD 

CDR 

CEC 

CM 

CMD 

CNO 

COEA 

CONOP 

CPB 

CPBR 

CRD 

CSSE 

CTV 

CWSE 


Command,  Control,  Communications,  Computers  and  Intelligence 

Cost  Analysis  Requirements  Description 

Critical  Design  Review 

Cooperative  Engagement  Capability 

Configuration  Management 

Cruise  Missile  Defense 

Chief  of  Naval  Operations 

Cost  and  Operational  Effectiveness  Analysis 

Concept  of  Operations 

Conceptual  Performance  Baseline 

Conceptual  Performance  Baseline  Review 

Capstone  Requirements  Document 

Chief  Ship  Systems  Engineer 

Control  Test  Vehicle 

Chief  Warfare  Systems  Engineer 


DAB  Defense  Acquisition  Board 

DLA  Defense  Intelligence  Agency 

DPG  Defense  Planning  Guidance 

DOD  Department  of  Defense 

DRM  Design  Reference  Mission 

DSP  Defense  Support  Program 


EADSIM 

EADTB 

EXCOM 

FCA 

FUE 


Extended  Air  Defense  Simulation 
Extended  Air  Defense  Test  Bed 
Exterior  Communication  System 
Functional  Configuration  Audit 
First  Unit  Equipped 
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GCCS 

GPS 

GTV 

IPPT 

IPT 

JCTN 

JDN 

JHU/APL 

JMCIS 

JMCOMS 

JNTF 

JPN 

JROC 

JTAMDO 

JTIDS 

KW 

LCC 

LEAP 

M&S 

MIT/LL 

MNS 

MOEs 

MSC 

MSRR  . 

N4 

N6 

N865 

NAEM 

NAVSEA 

NRL 

NSWC 

NSWCDD 

NTW 

O&S 

OPN 

OPNAV 

OPSIT 


ACRONYMS  AND  ABBREVIATIONS  (Continued) 

Global  Command  and  Control  System 
Global  Positioning  System 
Guided  Test  Vehicle 

Integrated  Product/Process  Improvement 
Integrated  Product  Team 

Joint  Composite  Training  Network 
Joint  Data  Network 

Johns  Hopkins  University/ Applied  Physics  Laboratory 

Joint  Maritime  Command  Information  System 

Joint  Maritime  Communications 

Joint  National  Test  Facility 

Joint  Planning  Network 

Joint  Requirements  Oversight  Committee 

Joint  Theater  Air  Missile  Defense  Office 

Joint  Tactical  Information  Distribution  System 

Kinetic  Warhead 

Life  Cycle  Cost 

Lightweight  Exo-Atmospheric  Projectile 
Modeling  and  Simulation 

Massachusetts  Institute  of  Technology  /  Lincoln  Laboratory 

Mission  Needs  Statement 

Measures  of  Effectiveness 

Mission  Success  Criteria 

Mission  System  Requirements  Review 

Deputy  Chief  of  Naval  Operations  (Logistics) 

OPNAV  Director,  Space  Information  Warfare  Command  and  Control 

OPNAV  Director  Theater  Air  Warfare 

Naval  Air  Engagement  Model 

Naval  Sea  Systems  Command 

Naval  Research  Laboratory 

Naval  Surface  Warfare  Center 

Naval  Surface  Warfare  Center  -  Dahlgren  Division 

Navy  Theater  Wide  Theater  Ballistic  Missile  Defense 

Operations  and  Support 
Operations  Procurement  Navy 
Office  of  Chief  of  Naval  Operations 
Operational  Situations 
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ACRONYMS  AND  ABBREVIATIONS  (Continued) 


ORD 

Operational  Requirements  Document 

ORR 

Operational  Requirements  Review 

PCA 

Physical  Configuration  Audit 

PEO 

Program  Executive  Officer 

PEO  SC 

Program  Executive  Officer,  Surface  Combatants 

PEO(TAD) 

Program  Executive  Officer,  Theater  Air  Defense 

PEO(TAD)-SE 

Program  Executive  Officer,  Theater  Air  Defense  Systems  Engineering 

PDR 

Preliminary  Design  Review 

PM 

Program  Manager 

POM 

Program  Objectives  Memorandum 

RDT&E 

Research  Development  Test  and  Evaluation 

ROE 

Rules  of  Engagement 

RRA 

Risk  Reduction  Activities 

SBIRS 

Space  Based  Infrared  System 

SCN 

Shipbuilding  and  Construction  Navy 

SE 

Systems  Engineering 

SEIPT 

Systems  Engineering  Integrated  Product  Team 

SECNAV 

Office  of  Secretary  of  the  Navy 

SEIPT 

Systems  Engineering  IPT 

SEP 

Systems  Engineering  Plan 

SEM 

Systems  Engineering  Memorandum 

SEMP 

Systems  Engineering  Management  Plan 

SETAT 

Systems  Engineering  Technical  Assessment  Team 

SFR 

System  Functional  Review 

SMTS 

Space  Missile  Tracking  System 

SPAWAR 

Naval  Space  Warfare  Command 

SRD 

System  Requirements  Document 

SRR 

Software  Requirements  Review 

SSR 

Specific  System  Representation  (EADTB) 

SSR 

Software  Specification  Review 

STAR 

System  Threat  Assessment  Report 

T&E 

Test  and  Evaluation 

TAD 

Theater  Air  Defense 

TBM 

Theater  Ballistic  Missile 

TBMD 

Theater  Ballistic  Missile  Defense 

TDDS 

Tactical  Data  Distribution  System 

TFCC 

Tactical  Flag  Communications  Center 

THADD 

Theater  High  Altitude  Air  Defense 

TIBS 

Tactical  Information  Broadcast  System 

TIMS 

TFCC  Information  Management  System 
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TLR 

TMD 

TRR 

UOES 

VLS 

WBS 

WPN 


ACRONYMS  AND  ABBREVIATIONS  (Continued) 

Top  Level  Requirement 
Theater  Missile  Defense 
Test  Readiness  Review 

User  Operational  Evaluation  System 

Vertical  Launching  System 

Work  Breakdown  Structure 
Weapons  Procurement  Navy 
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DELIVERABLES 

The  following  list  shows  the  deliverables  required  by  this  plan: 


1.  Svstem  Reauirements 
Document  (SRD)  Deliverables 

Due  Upon  Completion 

ISRilil 

wmm 

wsasm 

BO 

Scope  of  the  System 

Initial 

Draft 

Final 

Threats  and  Environment 

Initial 

Draft 

Preliminary 

Final 

Operational  Requirements 

Initial 

Draft 

Preliminary 

Final 

Functional  Requirements 

Initial 

Draft 

Preliminary 

Final 

o 

Technical  Performance  /  MOEs 

Preliminary 

Final 

Allocated  Functionality  / 
Performance 

o 

Interface  Requirements 

Initial 

Draft 

Final 

mm 

Verification  Requirements 

Final 

Final  SRD 

Final 

Approved  SRD 

X 

DUE  AT: 

2.  STEPE 

2.  E-l  Draft  Recommendation  for  the  Naval  TBMD  ORD  Completion  of  Step 


2.  E-2  Operational  Requirements  Report 


Completion  of  Step 
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DELIVERABLES  (Continued) 


3.  STEPF 

DUE  AT: 

3.  F-l  Design  Reference  Mission  (DRM) 

Completion  of  Step 

3.  F-2  Analysis  Report 

Completion  of  Step 

4.  STEP  G 

4.  G-l  NTW  Hierarchical  Functional  Descriptions 

Completion  of  Step 

4.  G-2  NTW  Interoperability  Requirements 

Completion  of  Step 

4.  G-3  NTW  Interface  Description  and  Functional  Flow 

Diagrams 

Completion  of  Step 

5.  STEPH 

5.  H-l  NTW  Conceptual  Performance  Baseline 

Completion  of  Step 

5.  H-2  NTW  System  Attribute  and  Success  Criteria  Report 

Completion  of  Step 

5.  H-3  NTW  Sensitivity  Analysis  Report 

Completion  of  Step 

6.  STEP.T 

6.  J-l  Baseline  Report  (Functional  Baseline,  System 

Architecture  and  NTW  Allocated  Baseline) 

Completion  of  Step 

6.  J-2  Migration  Path  Report 

Completion  of  Step 

6.  J-3  Non-NTW  Systems  Interface  Requirements 
Recommendations  Report 

Completion  of  Step 

6.  J-4  Technology  Developments  Requirements  Report 

Completion  of  Step 

6.  J-5  Interface  Sensitivity  Analysis  Report 

Completion  of  Step 
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